|
Версия 6.4 |
|
| ||||||||||||||||||||||||||||||||||||
Обслуживание Больших ДоменовЕсли некоторые из обслуживаемых вами Доменов имеют большое число Пользователей (5,000 или больше), то целесообразно хранить пользовательские данные в Поддиректориях для Пользователей, а не в "плоской" директории домена. Эта рекомендация основывается на методе, который файловая система использует для обслуживания списка записей в индексе директории; максимальное рекомендуемое число записей сильно зависит от типа используемой файловой системы. Например, файловая система с распределённым индексом директории в состоянии эффективно работать с большим количеством записей, чем файловая система, которая имеет один плоский файл с индексом директории. Некоторые файловые системы могут легко работать с индексами, имеющими более 50,000 записей, тогда как другие существенно замедляют свою работу уже при 1,000. Этот же принцип применяется к сайтам с 2,000 доменов в сервере/кластере или более. При таком сценарии рекомендуется использовать Поддиректории для Доменов Вы можете хранить поддиректории на нескольких логических томах; если это необходимо для обеспечения требуемого объёма или производительности - просто замените передвигаемые поддиректории символьными ссылками на них. Вы так же можете передвинуть директории с доменами из директории Domains и заменить их символьными ссылками. Обработка больших объёмов Местной ДоставкиЕсли предполагается, что число сообщений, доставляемое локальным пользователям CommuniGate Pro, превысит уровень 1 сообщения в секунду, то вы должны настроить большее количество "процессоров" в Модуле Местной Доставки. Это особенно важно для конфигураций, обрабатывающих большой входной SMTP трафик (часто встречающихся в тестовых средах для оценки производительности). Недостаточное число процессоров (нитей) для модуля Местной Доставки может привести к быстрому росту Очереди и большим задержкам в доставке сообщений. Вы должны наблюдать за работой модуля Местной Доставки и выделять больше процессоров (нитей) этому модулю, если вы видите, что в модуле Очередь выросла больше чем на 200-300 сообщений. Не выделяйте дополнительные нити если, например, у вас есть 10 процессоров для Местной Доставки и вы видите ожидающую Местной Доставки очередь из 200 сообщений; такая очередь приведёт всего лишь к 1-2 секундной задержке в доставке. Увеличивайте число нитей Местной Доставки только в том случае, если вы видите, что Очередь растёт. Некоторые типы массивов для хранения данных работают лучше при большом числе параллельно работающих нитей. Например, существуют некоторые массивы с сетевыми файловыми системами, которые могут доставлять сообщения быстрее со 100 процессорами Местной Доставки, а не с 10 для того же числа сообщений. Запросите производителя системы хранения данных дополнительную информацию об оптимальном числе параллельно выполняющихся операций записи для каждой из систем, обращающихся к массиву, и установите число процессоров Местной Доставки CommuniGate Pro в соответствии с этим числом. Так как процессоры Местной Доставки статичны (указанное число процессоров будет существовать все время, пока живёт процесс), важно указать достаточное количество процессоров, но не растрачивать системные ресурсы на их чрезмерное количество. Администраторы высоконагруженных Серверов могут выключить опцию Обновлять Консервативно (расположенную в панели Локальные Пользователи на странице Прочее в области Установки). Выключение этой опции уменьшает нагрузку на подсистему ввода/вывода. Поддержка множества одновременно работающих КлиентовПри крупных внедрениях большое число одновременно работающих пользователей является одной из самых больших проблем. Для того, чтобы оценить сколько пользователей вы можете обслуживать одновременно, вы должны примерно представлять какими услугами будут в основном пользоваться ваши клиенты.
Тонкая регулировка СистемыПри оптимизации производительности системы следует также уделить внимание некоторым настройкам ядра системы и 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):
Описание: Этот параметр задаёт продолжительность времени, в течение которого соединение будет оставаться в состоянии 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 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 XMac OS X устанавливает 6 мегабайтный лимит на "дополнительную" виртуальную память, запрашиваемую приложением. Этого количества недостаточно для сайтов, обслуживающих более, чем 2,000 пользователей, и вы должны увеличить этот лимит, указав в файле Startup.sh: ulimit -d 1048576 ulimit -n 16384 |