Масштабируемость
В этом разделе объясняется, как оптимизировать сервер CommuniGate Pro и ОС сервера для достижения максимальной производительности.
Для горизонтального масштабирования и дублирования критических узлов системы с использованием нескольких одновременно работающих серверов целесообразно использовать также кластерные конфигурации.
Обслуживание больших доменов
Если некоторые из обслуживаемых вами доменов имеют большое число пользователей (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 доставки
При обслуживании больших объёмов 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 32768LD_PRELOAD=libmtmalloc.so
ncsize
Параметр ядра Solarisncsize должен быть уменьшенна больших системах, в особенности на 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=4096set rlim_fd_max=16384* tcp connection hash sizeset tcp:tcp_conn_hash_size=16384
Обратите внимание: изменения в /etc/system вступят в силу только после перезагрузки системы.
Другие опции ядра:
# solaris 9/10 uses a default of 49152ndd -set /dev/tcp tcp_recv_hiwat 49152 # or 65536ndd -set /dev/tcp tcp_xmit_hiwat 49152 # or 65536# increase the connection queuendd -set /dev/tcp tcp_conn_req_max_q 512ndd -set /dev/tcp tcp_conn_req_max_q0 5120# decrease timersndd -set /dev/tcp tcp_fin_wait_2_flush_interval 135000ndd -set /dev/tcp tcp_time_wait_interval 60000ndd -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.1export LD_ASSUME_KERNEL
Ниже приводятся некоторые дополнительные регулировки для Linux с версией ядра 2.4. В большинстве поставок Linux, эти команды оболочки должны быть помещены в сценарий загрузки, выполняемый при старте системы. RedHat и некоторые другие поставки могут также иметь возможность настройки «sysctl» данных в файле /etc/sysctl.conf:
#!/bin/sh# Linux 2.4 tuning script# max open filesecho 131072 > /proc/sys/fs/file-max# kernel threadsecho 131072 > /proc/sys/kernel/threads-max# socket buffersecho 65536 > /proc/sys/net/core/wmem_defaultecho 1048576 > /proc/sys/net/core/wmem_maxecho 65536 > /proc/sys/net/core/rmem_defaultecho 1048576 > /proc/sys/net/core/rmem_max# netdev backlogecho 4096 > /proc/sys/net/core/netdev_max_backlog# socket bucketsecho 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets# port rangeecho '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 filesecho 131072 > /proc/sys/fs/file-max# kernel threadsecho 131072 > /proc/sys/kernel/threads-max# socket buffersecho 65536 > /proc/sys/net/core/wmem_defaultecho 1048576 > /proc/sys/net/core/wmem_maxecho 65536 > /proc/sys/net/core/rmem_defaultecho 1048576 > /proc/sys/net/core/rmem_max# netdev backlogecho 4096 > /proc/sys/net/core/netdev_max_backlog# socket bucketsecho 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets# port rangeecho '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 sizekern.dfldsiz="1G" # initial data size limitkern.maxssiz="128M" # max stack sizekern.ipc.nmbclusters="65536" # set the number of mbuf clustersnet.inet.tcp.tcbhashsize="16384" # size of the TCP control-block hashtable
FreeBSD 5 и выше
Настройки sysctl также могут устанавливаться автоматически через файл/etc/sysctl.conf:
# cache dir locations, on by defaultvfs.vmiodirenable=1# increase socket bufferskern.ipc.maxsockbuf=1048576kern.ipc.somaxconn=4096# increase default buffer sizenet.inet.tcp.sendspace=65536net.inet.tcp.recvspace=65536# decrease time waitnet.inet.tcp.keepidle=300000net.inet.tcp.keepintvl=30000# increase vnodeskern.maxvnodes=131072# increase maxfiles/maxfiles per processkern.maxfiles=131072kern.maxfilesperproc=65536# increase port rangenet.inet.ip.portrange.last=65535# default: net.inet.ip.rtexpire: 3600net.inet.ip.rtexpire=300# decrease MSL from 30000net.inet.tcp.msl=10000# increase max threads per process from 1500kern.threads.max_threads_per_proc=5000
HP-UX
Параметры ядра HP-UX могут, в зависимости от используемой версии HP-UX, устанавливаться с использованием различных механизмов. Следующие параметры ядра важно установить в значения большие, чем предполагаемая пиковая загрузка:
maxfiles Soft file limit per processmaxfiles_lim Hard file limit per processesmaxdsiz Maximum size of the data segmentnfile Maximum number of open filesninode Maximum number of open inodes# suggested parameter settingsmaxfiles 4096maxfiles_lim 32768maxdsiz (2048*1024*1024)nfile 32768ninode 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 1048576ulimit -n 16384