Масштабируемость

Если некоторые из обслуживаемых вами Доменов имеют большое число Пользователей (5,000 или больше), то целесообразно хранить пользовательские данные в Поддиректориях для Пользователей, а не в "плоской" директории домена. Эта рекомендация основывается на методе, который файловая система использует для обслуживания списка записей в индексе директории; максимальное рекомендуемое число записей сильно зависит от типа используемой файловой системы.

Например, файловая система с распределённым индексом директории в состоянии эффективно работать с большим количеством записей, чем файловая система, которая имеет один плоский файл с индексом директории. Некоторые файловые системы могут легко работать с индексами, имеющими более 50,000 записей, тогда как другие существенно замедляют свою работу уже при 1,000.

Этот же принцип применяется к сайтам с 2,000 доменов в сервере/кластере или более. При таком сценарии рекомендуется использовать Поддиректории для Доменов

Вы можете хранить поддиректории на нескольких логических томах; если это необходимо для обеспечения требуемого объёма или производительности - просто замените передвигаемые поддиректории символьными ссылками на них. Вы так же можете передвинуть директории с доменами из директории Domains и заменить их символьными ссылками.

Если предполагается, что число сообщений, доставляемое локальным пользователям CommuniGate Pro, превысит уровень 1 сообщения в секунду, то вы должны настроить большее количество "процессоров" в Модуле Местной Доставки. Это особенно важно для конфигураций, обрабатывающих большой входной SMTP трафик (часто встречающихся в тестовых средах для оценки производительности). Недостаточное число процессоров (нитей) для модуля Местной Доставки может привести к быстрому росту Очереди и большим задержкам в доставке сообщений. Вы должны наблюдать за работой модуля Местной Доставки и выделять больше процессоров (нитей) этому модулю, если вы видите, что в модуле Очередь выросла больше чем на 200-300 сообщений. Не выделяйте дополнительные нити если, например, у вас есть 10 процессоров для Местной Доставки и вы видите ожидающую Местной Доставки очередь из 200 сообщений; такая очередь приведёт всего лишь к 1-2 секундной задержке в доставке. Увеличивайте число нитей Местной Доставки только в том случае, если вы видите, что Очередь растёт.

Некоторые типы массивов для хранения данных работают лучше при большом числе параллельно работающих нитей. Например, существуют некоторые массивы с сетевыми файловыми системами, которые могут доставлять сообщения быстрее со 100 процессорами Местной Доставки, а не с 10 для того же числа сообщений. Запросите производителя системы хранения данных дополнительную информацию об оптимальном числе параллельно выполняющихся операций записи для каждой из систем, обращающихся к массиву, и установите число процессоров Местной Доставки CommuniGate Pro в соответствии с этим числом. Так как процессоры Местной Доставки статичны (указанное число процессоров будет существовать все время, пока живёт процесс), важно указать достаточное количество процессоров, но не растрачивать системные ресурсы на их чрезмерное количество.

Администраторы высоконагруженных Серверов могут выключить опцию Обновлять Консервативно (расположенную в панели Локальные Пользователи на странице Прочее в области Установки). Выключение этой опции уменьшает нагрузку на подсистему ввода/вывода.

При крупных внедрениях большое число одновременно работающих пользователей является одной из самых больших проблем. Для того, чтобы оценить сколько пользователей вы можете обслуживать одновременно, вы должны примерно представлять какими услугами будут в основном пользоваться ваши клиенты.

Клиенты POP3

Почтовые программы, работающие по протоколу POP3, соединяются с сервером и просто загружают новые сообщения. На основании средней скорости соединения, ожидаемого почтового трафика и привычек ваших пользователей вы можете оценить, сколько времени продолжается средняя сессия. Например, если вы Интернет провайдер, и вы предполагаете, что в среднем операция "проверки почты" будет занимать 15 секунд, и в основном клиенты будут проверять свою почту в среднем два раза в течение 12 часов пиковой загрузки, то имея 100,000 пользователей POP3 вы можете ожидать 100,000 * 2 12*60*60 15 секунд / (12 * 60 * 60 секунд) = ~70 одновременно происходящих POP3 сессий.

Это число не очень велико, но сессии POP3 создают высокую нагрузку на дисковую и сетевую подсистемы ввода/вывода: после аутентификации, POP3 сессия мало чем отличается от простой "загрузки файлов".

Клиенты IMAP4

Протокол IMAP4 позволяет осуществлять намного более сложные операции, чем POP3. В основном, почта остаётся на сервере, а некоторые ненужные сообщения могут удаляться пользователями даже без загрузки их в свои почтовые программы.

Протокол IMAP является протоколом "доступа к почте", а не протоколом "скачивания почты". IMAP пользователи проводят существенно больше времени, оставаясь на связи с сервером. В корпоративной среде, пользователи могут держать свои IMAP сессии открытыми часами, а то и сутками. Хотя такие неактивные сессии не создают никакую нагрузку ни на вашу дисковую или сетевую подсистему ввода/вывода, ни на центральный процессор, для каждой сессии все же требуется открытое сетевое соединение и обрабатывающая его нить на сервере. Так как IMAP протокол позволяет пользователям производить операции поиска на сервере, IMAP пользователи могут также потреблять много ресурсов центрального процессора, если они часто пользуются такой возможностью.

При поддержке большого количество IMAP или POP соединений, важно настроить много IMAP и POP каналов, для того, чтобы позволить большому количеству пользователей работать одновременно. Некоторые современные IMAP клиенты и MAPI-Коннектор могут даже открывать несколько соединений для одного пользователя, и каждое из них учитывается в общем количестве используемых IMAP каналов. К счастью, IMAP и POP каналы создаются только в момент их использования, так что если число IMAP и POP каналов установлено в 10,000, а используется только 2,000, то системные ресурсы не используются - однако, будьте осторожны, чтобы не устанавливать это значение ниже определённой границы, когда ваша система будет не в состоянии обслуживать новые соединения и даже может прекратить отвечать на запросы пользователей, уже установивших соединение. Настройки IMAP и POP каналов задают некоторый лимит, защищающий ресурсы вашей системы (или кластера) от перегрузки в случае пика или при атаках на отказ в обслуживании.

Клиенты WebUser

Веб Интерфейс Пользователя CommuniGate Pro предоставляет такие же возможности, как и почтовые клиенты IMAP, но он не требуют того, чтобы сетевые соединения (и обрабатывающие их нити) были открыты всё время для каждой сессии пользователя. Когда клиент (бразуер) отправляет запрос, устанавливается сетевое соединение, запрос обрабатывается нитью сервера, и соединение закрывается.

Это позволяет Серверу использовать всего лишь 100 HTTP соединений для обслуживания 3,000 открытых сессий (или даже больше).

CommuniGate Pro также поддерживает опцию HTTP 1.1 "Keep Alive", которая задаётся на странице Установки в Веб Интерфейсе Пользователя и называется "Поддерживать 'Keep-Alive'". Работа в HTTP Keep-Alive сессии для Пользователей, работающих через Веб Интерфейс приведёт к тому, что каждая WebUser сессия будет держать одно или более открытых соединений браузера пользователя с сервером в течение всей сессии. Этот метод не рекомендуется использовать на загруженных системах, так как он потребляет значительные ресурсы центрального процессора и операционной системы; однако, если система в состоянии справиться этой повышенной нагрузкой, то он может быть полезным для оптимизации времени ответа системы на запросы Клиента WebUser. В Кластере соединения Keep-Alive могут обслуживаться только на Frontend Серверах.

Клиенты SIP/RTP

По сравнению с передачей почтовых сообщений, которая в большей мере ограничивается производительностью дисковой подсистемы, передача SIP и RTP данных осуществляется в реальном времени и только иногда (в действиях типа SIP REGISTER) нагружает дисковую подсистему ввода/вывода. Трафик реального времени очень чувствителен к любым сетевым задержкам или задержкам, причиняемым системой, и зависит от производительности центрального процессора в большей степени, чем передача сообщений. Однако сегодняшние системы, с их постоянно увеличивающейся скоростью центрального процессора и центральной шины, в общем удовлетворяют требованиям производительности для обмена трафиком реального времени.

Для того, чтобы оптимизировать SIP и RTP производительность, Сервер CommuniGate Pro должен работать на современной системе с адекватным процессором и объёмом памяти. Если большая часть трафика, обслуживаемого CommuniGate Pro, является сигнальным трафиком SIP, то даже однопроцессорный сервер в состоянии будет обслуживать до 100 вызовов в секунду. Однако, в случае если осуществляется большое количество операций медиа-проксирования, SIP и RTP проксирования, прохождения NAT, а также активно используются функции АТС, то требования к памяти, пропускной способности сети и особенно к производительности центрального процессора сильно возрастают.
Если потребуется, то увеличьте число процессоров, обслуживающих Транзакции SIP Сервера и Транзакции SIP Клиента, а также число процессоров Сигналов.
Эти нити являются "статичными", что означает, что нити создаются независимо от того, используются они или нет, потребляя некоторое количество памяти для своих нужд.

При оптимизации производительности системы следует также уделить внимание некоторым настройкам ядра системы и TCP/UDP стека, изменяя которые, можно добиться как существенного увеличения числа одновременно обслуживаемых сетевых соединений, так и повышения количества открытых дескрипторов файлов, обрабатываемых CommuniGate Pro. Большинство операционных систем позволяют регулировать эти опции; методы, которые используются для этой цели, сильно отличаются от системы к системе, и, возможно, в некоторых случаях вам потребуется обратиться к производителю системы или провести небольшое исследование, чтобы выяснить, каким образом это делается в используемой вами системе.

Число доступных дескрипторов файлов должно быть примерно в два раза больше, чем число одновременных IMAP, POP, SMTP, SIP/RTP и других используемых соединений. Вы также должны быть уверены, что операционная система в состоянии эффективно открывать много TCP/UDP сокетов одновременно - некоторые ОС имеют "ассоциативный массив" ("хеш-таблицу") обслуживаемых сокетов, и размер этого массива должен быть задан больше, чем число требуемых сокетов. В большинстве случаев 8192 сокета и 16384 открытых дескрипторов файлов на процесс будет вполне достаточно, даже если система работает под большой нагрузкой. Избегайте чрезмерного увеличения этих значений, так как в большинстве случаев это приводит к повышенному потреблению памяти. Снятие в оболочке лимита на число открытых дескрипторов файлов также может привести к проблемам на некоторых операционных системах, так как это может вывести дескрипторы файлов за 32-битные или 64-битные значения, что, в свою очередь, может привести к повышенному расходу памяти и ресурсов центрального процессора.

Установка таймера TCP TIME_WAIT

Если предполагается обслуживать большое число TCP/IP соединений, то важно проверить время ожидания сервера перед высвобождением логически закрытого TCP/IP соединения. Если это время слишком велико, то на эти "мёртвые" сокеты могут быть израсходованы все TCP/IP ресурсы ОС; все новые соединения будут отвергаться на уровне ОС, так что Сервер CommuniGate Pro будет даже не в состоянии предупредить вас о том, что это происходит.

Эта проблема может наблюдаться даже на сайтах, обслуживающих всего лишь несколько сотен пользователей. Это свидетельствует о том, что некоторые из клиентов настроили свои почтовые программы на слишком частые соединения с сервером. Если клиентская почтовая программа соединяется с сервером каждую минуту, а время TIME_WAIT сервера установлено в 2 минуты, то число "мёртвых" сокетов будет все время расти, и, в конце концов, потребит все TCP/IP ресурсы системы.

По умолчанию TIME_WAIT на многих системах имеет значение в 120 или 240 секунд; некоторые операционные системы стали по умолчанию устанавливать значение TIME_WAIT в 60 секунд, хотя, видимо, значение в 20-30 секунд является достаточно безопасным.

Проблема TIME_WAIT особенно часто встречается в системах Windows. В отличие от большинства Unix систем, в Windows NT нет стандартной настройки, отвечающей за изменение интервала TIME_WAIT. Для изменения этой настройки, вы должны создать в Windows NT ключ в Системном Реестре (информация взята с сайта http://www.microsoft.com):

• Запустите редактор Системного Реестра (RegEdit.exe)
• Найдите следующий ключ в реестре:
  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters
• Выберите значение Add Value в меню Edit и создайте следующую запись:

  Имя Значения:

  TcpTimedWaitDelay

  Тип Данных:

  REG_DWORD

  Значение:

  30-300 (десятичное) - время в секундах
  По умолчанию: 0xF0 (240 десятичное) в реестре не указывается

• Выйдите из Редактора Реестра
• Перезапустите компьютер для того, чтобы изменения в реестре вступили в силу.

Описание: Этот параметр задаёт продолжительность времени, в течение которого соединение будет оставаться в состоянии TIME_WAIT при закрытии. Пока соединение находится в состоянии TIME_WAIT, сокет не может быть использован снова. Это состояние известно так же как состояние 2MSL, и, согласно RFC, значение должно быть в два раза больше максимального времени жизни сегмента в сети. Дополнительную информацию о MSL смотрите в RFC793.

При обслуживании больших объёмов SMTP Доставки (более 50 сообщений в секунду), вам необходимо быть уверенным, что ваш DNS сервер сможет обрабатывать запросы, генерируемые CommuniGate Pro, и что при обмене UDP пакетами между CommuniGate Pro и DNS серверами не происходит сколько-нибудь существенной потери пакетов. Вы можете перенастроить маршрутизаторы в вашей сети, задав UDP трафику более высокий приоритет, чем TCP трафику.

Для того, чтобы отрегулировать параметры DNS Клиента, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Сеть, затем откройте страницу DNS Клиент.

Вы можете попытаться использовать различные значения для Параллельных Запросов: в зависимости от установок вашего DNS сервера, увеличение числа параллельно выполняемых запросов до 10-20 может привести к падению производительности сервера.

Если средний размер сообщения, пересылаемого через SMTP больше, чем 20K килобайт, то вы должны быть также осторожны при выборе числа SMTP каналов (нитей) для отправки сообщений. Слишком большое число одновременно пересылаемых сообщений может исчерпать пропускную способность вашей сети, что в результате также приведет к общему снижению производительности системы. 500 каналов, отправляющих данные на удалённые сайты с относительно медленными подключениями в 512 кбит/секунду могут порождать да 250 Мбит/секунду исходящего трафика с вашего сайта. Обычно трафик намного меньше, так как исходящие каналы затрачивают довольно много времени на обмен параметрами устанавливаемого соединения и передачу информации из конвертов сообщений. Но как только средний размер сообщения становится больше, основное время каналы начинают затрачивать на передачу реальных, а не служебных данных, что приводит к увеличению TCP трафика, порождаемого каналами.

Если на вашей системе установлено достаточное количество памяти, то при использовании Внешних Фильтров Сообщений SMTP - таких, как антивирусы, средства борьбы со спамом или другие средства фильтрования содержания сообщений, SMTP загрузка может быть оптимизирована путём размещения директории для временных файлов, используемых этими дополнительными модулями, в оперативной памяти или на специальной файловой системе типа tmpfs. Так как в CommuniGate Pro все сообщения, ожидающие своей очереди отправки, хранятся в реальной директории Queue, то размещение директории для временных файлов дополнительных модулей в оперативной памяти будет безопасным, поскольку в этих директориях никогда не содержится единственный экземпляр сообщения. И даже в случае ошибки, отказа по питанию или фатального сбоя в работе сервера CommuniGate Pro, любое недоставленное сообщение будет всегда ждать своей очереди на "устойчивом" носителе в нормальной директории Queue.

Каждое сетевое соединение нуждается в одном дескрипторе сетевого сокета для процесса сервера. В системах Unix общее число сокетов и файлов, открываемых одним процессом, ограничено.

Когда Сервер CommuniGate Pro запускается, он пытается установить для себя эти лимиты как можно выше, а затем, если он видит, что установленный лимит может достигать общего лимита всей системы, то он постепенно уменьшает этот лимит (так как если Сервер CommuniGate Pro заберёт для себя все доступные дескрипторы, то вероятнее всего это приведет к краху ОС Сервера). Используемый лимит записывается в Журнал работы CommuniGate Pro.

Для увеличения максимального числа дескрипторов файлов и сокетов, которые может открывать процесс Сервера CommuniGate Pro, ознакомьтесь с инструкциями ниже.

Каждое сетевое соединение обрабатывается сервером как нить. Каждая нить имеет свой собственный стек; на большинстве платформ нити CommuniGate Pro имеют стек в 128 килобайт. Большая часть памяти стека не используется, так что он не требует выделения реальной памяти, однако их запросы на память суммируются, что приводит к повышенному выделению виртуальной памяти. Большинство ОС не позволяет обрабатывать виртуальную память больше определённого лимита. Обычно, этот лимит бывает равен реальному размеру память плюс размер файла подкачки. Так, на системе с размером файла подкачки в 127 мегабайт и с 96 мегабайтами оперативной памяти, максимальная виртуальная память может составить около 220 мегабайт. Так как файл подкачки используется всеми процессами ОС, то эффективная виртуальная память на такой системе будет около 100-150 мегабайт, и, вероятнее всего, Сервер CommuniGate Pro сможет создать около 500-1000 нитей.

На 32-битных компьютерах, 4 гигабайта виртуальной памяти является теоретическим пределом адресуемой памяти (хотя в реальности лимит виртуальной памяти для процессов пользователя зачастую равен 2 гигабайтам), и выделение более чем 4 гигабайтов дискового пространства под файл подкачки не даст никаких преимуществ. Так как сегодня стоимость памяти существенно упала, то для того, чтобы получить максимум доступной памяти, для 32-битных систем рекомендуется устанавливать 4 гигабайта оперативной памяти, что позволит использовать одному процессу до 2 гигабайт (или больше) виртуальной памяти. При поддержке большого количества одновременных IMAP, POP3 или SIP/RTP соединений, в дополнение к другим потребностям в памяти, процесс CGServer будет расти в размере пропорционально общему размеру выделяемого под каждую нить стека. При необходимости поддержки более чем 4000 нитей, целесообразно использовать такую операционную систему, которая позволяет выделять более чем 2 гигабайта виртуальной памяти для процесса CGServer, и конечно, в такую систему должно быть установлено 4 гигабайта оперативной памяти.

В течение сессии доступа по протоколам POP3 или IMAP открывается одна из папок пользователя. Если эта папка является почтовым ящиком в формате текстового файла, то открывается соответствующий файл. В течение SMTP сессии для входящего сообщения создаётся временный файл, и он остаётся открытым до тех пор, пока сообщение не получено полностью. Таким образом, в системах Unix общее число открытых POP, IMAP, и SMTP соединений не может превышать половины от максимального числа дескрипторов сокетов/файлов, возможных для одного процесса. Для высокопроизводительных систем, возможно, целесообразным будет установить значение числа дескрипторов на один процесс равным 8192 или даже больше.

Хотя сессия WebUser не требует сетевого соединения (и, следовательно, выделенного сокета и нити), в ней может быть открыта более чем одна папка. (При использовании опции Поддерживать 'Keep-Alive' каждая WebUser сессия также будет потреблять как минимум одно сетевое соединение).

В системах Unix, когда Сервер обнаруживает, что число открытых сетевых сокетов и дескрипторов файлов подходит близко к пределу, он начинает отвергать входящие соединения и делает соответствующие записи об этой проблеме в Журнал.

В этом разделе объясняется, как оптимизировать ядро наиболее часто используемых вместе с CommuniGate Pro операционных систем и параметры TCP стека.

Наиболее часто встречающимися ограничениями являются:

• Дескрипторы открытых файлов - максимальное число файлов и сетевых сокетов, которые могут открываться в одном процессе.
• Максимальный размер виртуальной памяти, доступный для процесса.

Пожалуйста, уточните у производителя операционной системы, являются ли предлагаемые изменения безопасными для её устойчивой работы и всегда тестируйте изменения на тестовой системе прежде чем использовать их на работающем сервере. Различия в версиях операционных систем, установленных текущих обновлениях, аппаратном обеспечении и требованиях к рабочей нагрузке могут привести к отличиям оптимальных значений от рекомендуемых здесь. В этих примерах приводятся не всегда оптимальные значения для каждой конкретной ситуации.

Solaris

Применимо к Solaris версий 8, 9 и 10.

Файл "Startup.sh" CommuniGate Pro

По умолчанию файл Startup.sh находится в /var/CommuniGate/Startup.sh. Возможно, вам потребуется создать его. Этот файл читается сценарием запуска /etc/init.d/STLKCGPro.init и исполняется при загрузке.
Используемая по умолчанию библиотека malloc не слишком эффективна для многопоточных приложений, особенно, когда на сервере доступно более двух ядер центрального процессора, и библиотека mtmalloc может показать несколько лучшие результаты.
Ниже приводится файл Startup.sh, подходящий для большинства версий Solaris.

SUPPLPARAMS="--DefaultStackSize 131072 --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 32768
LD_PRELOAD=libmtmalloc.so

ncsize

Параметр ядра Solaris ncsize должен быть уменьшен на больших системах, в особенности на backend-серверах Динамических Кластеров. Кэш, которым управляет этот параметр, не может хранить сколько-нибудь полезный набор путей к файлам, но его большой размер заставляет систему тратить много циклов центрального процессора на проверку таблиц этого кэша (симптомы: использование более чем 50% ресурсов центрального процессора, ресурсы процессора тратятся на ядро системы). Уменьшите значение параметра ядра ncsize до 1000-2000.

Добавления в /etc/system

Приводимые ниже строки настроек подойдут для большинства систем Solaris, работающих под большой загрузкой. Хорошей оценкой для установки этих значений являются значения между одно- и двукратной ожидаемой пиковой загрузки системы.

* system file descriptor limit (setting the max setting to 32768 may
* be better in some instances)
set rlim_fd_cur=4096
set rlim_fd_max=16384
* tcp connection hash size
set tcp:tcp_conn_hash_size=16384

Обратите внимание: изменения в /etc/system вступят в силу только после перезагрузки системы.

Другие опции ядра:

# solaris 9/10 uses a default of 49152
ndd -set /dev/tcp tcp_recv_hiwat 49152 # or 65536
ndd -set /dev/tcp tcp_xmit_hiwat 49152 # or 65536
# increase the connection queue
ndd -set /dev/tcp tcp_conn_req_max_q 512
ndd -set /dev/tcp tcp_conn_req_max_q0 5120
# decrease timers
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 135000
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_keepalive_interval 30000
## naglim should likely only be disabled on Backends 
## 1=disabled, default is 53 (difficult to confirm)
# ndd -set /dev/tcp tcp_naglim_def 1

Windows

Системы Windows ограничивают максимальное число портов, используемых для исходящих соединений. По умолчанию, это значение равно 5000. Вы можете увеличить это значение до 20,000 или выше, добавив значение MaxUserPort типа DWORD в ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Реестра.

Дополнительную информацию смотрите в статье Microsoft Support Article Q196271.

Linux

Файл "Startup.sh" CommuniGate Pro

В Linux, файл Startup.sh по умолчанию находится в/var/CommuniGate/Startup.sh. Возможно, вам потребуется создать его. Этот файл читается сценарием запуска /etc/init.d/CommuniGate и исполняется при загрузке. Ниже приводится файл Startup.sh, подходящий для Linux версий 2.4 или выше. Возможно, вы столкнётесь с ситуацией, при которой вам потребуется больше дескрипторов файлов; в этом случае значение "ulimit -n" можно безопасно увеличивать до 32768.

SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 16384

Ядро Linux версии 2.6 и более поздних версий:

До версии 2.2. ядро Linux позволяло открывать только 256 дескрипторов файлов. Если вы хотите, чтобы ваш сервер обрабатывал более 100 TCP/IP соединений, используйте ядро Linux версии 2.2.x или выше для избегания проблемы "нехватки дескрипторов файлов".

Библиотеки нитей в Linux используют модель один-к-одному, так что каждая нить CommuniGate Pro является в действительности нитью ядра (фактически, "процессом"). Это не лучшее решение для очень больших систем, на которых должны работать несколько тысяч нитей.

Несмотря на то, что нити Linux обрабатываются ядром, в библиотеке нитей Linux так же имеется собственный диспетчер. По умолчанию, этот диспетчер использует статическую таблицу с 1024 записями; таким образом, невозможно создать более чем 1024 нити. Этого достаточно даже для довольно крупных сайтов, обслуживающих множество POP пользователей и пользователей, работающих через Интерфейс Веб Доступа, но может создать проблемы для сайтов, обслуживающих несколько сотен пользователей, работающих одновременно через IMAP. Для того, чтобы увеличить это число, библиотека нитей Linux должна быть перекомпилирована с увеличенным значением параметра PTHREAD_THREADS_MAX.

Библиотека нитей Linux размещает стек нитей с шагом 2 мегабайта. Это не позволяет системе запускать более 1000 нитей на 32-битных компьютерах. Нитям CommuniGate Pro не требуется стек такого размера. Вы можете перекомпилировать библиотеку нитей Linux, уменьшив значение параметра STACK_SIZE до 128K килобайт.

Linux kernel 2.4:

Ядро Linux версии 2.4 позволяет легко перенастраивать наиболее важные параметры. Однако, в некоторых поставках, основывающихся на версии 2.4, библиотека может быть скомпилирована с параметром PTHREAD_THREADS_MAX, установленным в значение 1024 или около того - в этом случае, библиотека нитей Linux должна быть перекомпилирована с увеличенным значением параметра PTHREAD_THREADS_MAX. Большинство поставок Linux версии 2.4 включают в себя библиотеку нитей "LinuxThreads". Существуют поставки Linux, основывающиеся на версии 2.4, в которые сделана попытка обратного портирования библиотеки нитей POSIX на ядро 2.4. - и в некоторых случаях, работа POSIX-нитей с ядром версии 2.4 гарантированно приводит к нестабильной работе многих приложений, включая CommuniGate Pro. При работе CommuniGate Pro на версии ядра 2.4. рекомендуется использовать библиотеку LinuxThreads. По умолчанию это обеспечивается сценарием запуска /etc/init.d/CommuniGate:

LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL

Ниже приводятся некоторые дополнительные регулировки для Linux с версией ядра 2.4. В большинстве поставок Linux, эти команды оболочки должны быть помещены в сценарий загрузки, выполняемый при старте системы. RedHat и некоторые другие поставки могут также иметь возможность настройки "sysctl" данных в файле /etc/sysctl.conf:

#!/bin/sh
# Linux 2.4 tuning script
# max open files
echo 131072 > /proc/sys/fs/file-max
# kernel threads
echo 131072 > /proc/sys/kernel/threads-max
# socket buffers
echo 65536 > /proc/sys/net/core/wmem_default
echo 1048576 > /proc/sys/net/core/wmem_max
echo 65536 > /proc/sys/net/core/rmem_default
echo 1048576 > /proc/sys/net/core/rmem_max
# netdev backlog
echo 4096 > /proc/sys/net/core/netdev_max_backlog
# socket buckets
echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets
# port range
echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_range

Обратите внимание: при работе с ядром Linux версии 2.4 и 2.6 в случае, если вы не используете iptables в сервере CommuniGate Pro, вы можете добиться заметного улучшения производительности сетевой подсистемы перекомпилировав ядро без NETFILTER (iptables).

Ядро Linux версии 2.6 и более поздних версий:

В ядре Linux версии 2.6. были представлены "Нити POSIX", которые заменили устанавливаемую ранее по умолчанию библиотеку нитей "LinuxThreads". Ядро версии 2.6. является первой версией Linux, на которой рекомендуется использование POSIX-нитей. При использовании ядра версии 2.6 и POSIX-нитей (использование поставки с установленным по умолчанию ядром 2.6. является предпочтительным), сценарий /etc/init.d/CommuniGate должен быть изменён и следующие строки должны быть закомментированы:

# LD_ASSUME_KERNEL=2.4.1
# export LD_ASSUME_KERNEL

Закомментировав эти строки, вы по умолчанию разрешите использование библиотек нитей POSIX (размещенным в /lib/tls/).

Ниже приводятся некоторые дополнительные регулировки для Linux версий 2.6. В большинстве поставок Linux, эти команды оболочки должны быть помещены в сценарий загрузки, выполняемый при старте системы. RedHat и некоторые другие поставки могут также иметь возможность настройки "sysctl" данных в файле /etc/sysctl.conf:

#!/bin/sh
# Linux 2.6 tuning script
# max open files
echo 131072 > /proc/sys/fs/file-max
# kernel threads
echo 131072 > /proc/sys/kernel/threads-max
# socket buffers
echo 65536 > /proc/sys/net/core/wmem_default
echo 1048576 > /proc/sys/net/core/wmem_max
echo 65536 > /proc/sys/net/core/rmem_default
echo 1048576 > /proc/sys/net/core/rmem_max
# netdev backlog
echo 4096 > /proc/sys/net/core/netdev_max_backlog
# socket buckets
echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets
# port range
echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_range

FreeBSD

Ниже приводятся некоторые дополнительные регулировки, применимые для FreeBSD разных версий.

Файл "Startup.sh" CommuniGate Pro

По умолчанию файл Startup.sh находится в /var/CommuniGate/Startup.sh. Возможно, вам потребуется создать его. Этот файл читается сценарием запуска /usr/local/etc/rc.d/CommuniGate.sh и исполняется при загрузке. Ниже приводится файл Startup.sh для CommuniGate Pro версии 4.3 или более поздней, подходящий для большинства версий FreeBSD. Возможно, вы столкнетесь с ситуацией, при которой вам потребуется больше дескрипторов файлов; в этом случае, значение "ulimit -n" можно безопасно увеличивать до 32768:

SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 16384

Для установки параметров ядра при загрузке системы, может использоваться файл /boot/loader.conf.local:

# increase the TCP connection hash to a value just greater than peak needs
# (this can be set higher if necessary)
net.inet.tcp.tcbhashsize="16384"

Конфигурационный файл Загрузчика /boot/loader.conf должен быть изменён:

kern.maxdsiz="1G"                # max data size
kern.dfldsiz="1G"                # initial data size limit
kern.maxssiz="128M"              # max stack size
kern.ipc.nmbclusters="65536"     # set the number of mbuf clusters
net.inet.tcp.tcbhashsize="16384" # size of the TCP control-block hashtable

FreeBSD 5 и выше

Настройки sysctl также могут устанавливаться автоматически через файл /etc/sysctl.conf:

# cache dir locations, on by default
vfs.vmiodirenable=1
# increase socket buffers
kern.ipc.maxsockbuf=1048576
kern.ipc.somaxconn=4096
# increase default buffer size
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=65536
# decrease time wait
net.inet.tcp.keepidle=300000
net.inet.tcp.keepintvl=30000
# increase vnodes
kern.maxvnodes=131072
# increase maxfiles/maxfiles per process
kern.maxfiles=131072
kern.maxfilesperproc=65536
# increase port range
net.inet.ip.portrange.last=65535
# default: net.inet.ip.rtexpire: 3600
net.inet.ip.rtexpire=300
# decrease MSL from 30000
net.inet.tcp.msl=10000
# increase max threads per process from 1500
kern.threads.max_threads_per_proc=5000

HP-UX

Параметры ядра HP-UX могут, в зависимости от используемой версии HP-UX, устанавливаться с использованием различных механизмов. Следующие параметры ядра важны установить в значения большие, чем предполагаемая пиковая загрузка:

  maxfiles      Soft file limit per process
  maxfiles_lim  Hard file limit per processes
  maxdsiz       Maximum size of the data segment
  nfile         Maximum number of open files
  ninode        Maximum number of open inodes
  
  # suggested parameter settings
  maxfiles      4096
  maxfiles_lim  32768
  maxdsiz       (2048*1024*1024)
  nfile         32768
  ninode        32768

Также рекомендуется уменьшить значение параметра TCP TIME_WAIT:

ndd -set /dev/tcp tcp_time_wait_interval 60000

Mac OS X

Mac OS X устанавливает 6 мегабайтный лимит на "дополнительную" виртуальную память, запрашиваемую приложением. Этого количества недостаточно для сайтов, обслуживающих более, чем 2,000 пользователей, и вы должны увеличить этот лимит, указав в файле Startup.sh:

ulimit -d 1048576
ulimit -n 16384