kern.maxfiles
Значение kern.maxfiles
может быть увеличено или
уменьшено в зависимости от потребностей вашей системы. Эта переменная определяет
максимальное число дескрипторов файлов. Когда таблица дескрипторов файлов полна, в
очереди системных сообщений появится сообщение “file:
table is full”. Это сообщение может быть прочитано с помощью команды
dmesg.
Каждый открытый файл, сокет или буфер использует дескриптор файла. Широкомасштабному серверу может понадобиться много тысяч дескрипторов файлов, в зависимости от количества программ, одновременно выполняемых на сервере.
Стандартное значение kern.maxfile
определяется
переменной maxusers
в вашем файле конфигурации ядра.
Значение kern.maxfiles
увеличивается пропорционально
значению maxusers
. При компилировании ядра, нужно
установить эту переменную согласно потребностям вашей системы. Исходя из значения
этой переменной, ядро устанавливает значения большинства предопределённых
переменных. Даже если предполагается, что к компьютеру не будут одновременно
подсоединяться 256 пользователей, требуемые ресурсы могут быть такими же, как у
крупномасштабного сервера.
Система автоматически настроит maxusers, если вы явно установите его в 0[1]. Если вы желаете выставить значение самостоятельно, то задайте maxusers по меньшей мере равным 4, особенно если вы используйте X Window System или компилируйте программное обеспечение. Причина в том, что самая значимая таблица, устанавливаемая maxusers - это максимальное количество процессов, которая устанавливается равным 20 + 16 * maxusers, и поэтому, если вы установите maxusers в 1, то вы сможете иметь только 36 одновременных процессов, включая 18 или около того, что система запустит во время загрузки и 15 или около того, что вы создадите при запуске X Window System. Даже простая задача, как чтение страницы справочника породит 9 процессов для фильтрации, декомпрессии и её просмотра. Установка maxusers в 64 позволит иметь вам до 1044 одновременных процессов, чего должно быть достаточно примерно для всех использований. Если, тем не менее, вы увидите пугающую ошибку proc table full при попытке запуска другой программы, или вы используйте сервер с большим количеством одновременных пользователей (как ftp.FreeBSD.org), то вы всегда можете увеличить значение и пересобрать систему.
Замечание: maxusers не ограничивает количество пользователей, которые могут заходить на вашу машину. Оно просто устанавливает различные размеры таблиц в разумные значения, учитывая максимальное количество пользователей, вы вероятно будете иметь на вашей системе и как много процессов каждый из них сможет запускать. Ключевое слово, которое ограничивает количество одновременных удаленных входов и терминальных X окон - это pseudo-device pty 16. С FreeBSD 5.X вам не надо беспокоиться об этом значении, так как pty(4) драйвер является ''автоматически клонирующим''; вы просто используйте device pty в вашем конфигурационном файле.
kern.ipc.somaxconn
Переменная sysctl kern.ipc.somaxconn
ограничивает
размер очереди для приема новых TCP соединений. Значение по умолчанию 128 слишком мало для надежной обработки новых соединений для
нагруженного web сервера. Для такого сервера рекомендуется увеличить это значение
до 1024 или выше. Даемон сервиса может сам
ограничивать очередь приема новых соединений (например, sendmail(8), или Apache), но обычно в файле настройки даемона есть директива
для настройки длины очереди. Более длинная очередь также помогает избежать
атак Denial of Service (DoS).
Опция ядра NMBCLUSTERS обуславливает количество Mbuf,
доступных на машине. На сервере с большим трафиком и маленьким Mbuf
производительность будет пониженной. Каждый кластер представлен двумя килобайтами
памяти, поэтому значение 1024 означает 2 мегабайта памяти ядра, зарезервированной
для сетевых буферов. Для определения оптимального значения необходимо провести
простые вычисления. Если у вас веб сервер, который может обслуживать 1000
одновременных соединений, и каждое соединение ''съедает'' 16 K буфера
приема и 16 K буфера отправки, вам потребуется 32 MB памяти под
буферы. Хорошее правило — умножение этого значения на 2,
2x32 MB / 2 KB = 64 MB / 2 kB =
32768. Мы рекомендуем значения между 4096 и 32768 для машин с большим объемом
памяти. Не указывайте произвольно большое значение параметра, это может
привести к падению системы при загрузке. Используйте netstat(1) с опцией
-m
для определения количества используемых сетевых
кластеров.
Для настройки в процессе загрузки используйте в loader переменную kern.ipc.nmbclusters
. Только в старых версиях FreeBSD
потребуется пересобрать ядро (config(8)) с
измененным параметром NMBCLUSTERS.
Для нагруженных серверов, интенсивно использующих системный вызов sendfile(2), может
потребоваться увеличения буферов sendfile(2) с помощью
параметра конфигурации ядра NSFBUFS, или изменения значения
путем установки переменной в /boot/loader.conf
(обратитесь к loader(8) за
подробностями). Общий признак того, что параметр требуется изменить —
состояние процессов sfbufa. Переменная sysctl kern.ipc.nsfbufs
установлена только для чтения. Этот параметр
увеличивается вместе с kern.maxusers
, хотя может
потребоваться увеличить его отдельно.
Важно: Даже если сокет помечен как неблокирующий, вызов sendfile(2) на неблокирующем сокете может вызвать блокирование sendfile(2), пока не станет доступным достаточное количество struct sf_buf.
net.inet.ip.portrange.*
Переменные sysctl net.inet.ip.portrange.*
контролируют диапазоны номеров портов, автоматически привязываемых к TCP и UDP
сокетам. Есть три диапазона: нижний диапазон, диапазон по умолчанию и верхний
диапазон. Большинство сетевых программ используют диапазон по умолчанию,
контролируемый net.inet.ip.portrange.first
и
net.inet.ip.portrange.last
, установленными
соответственно в 1024 и 5000. Диапазоны портов привязки используются для исходящих
соединений и при некоторых условиях портов может не хватить. Это чаще всего
происходит на сильно загруженном прокси сервере. Диапазон портов не
становится проблемой при работе серверов, которые обрабатывают в основном входящие
соединения, или с небольшим количеством исходящих соединений, например mail relay.
Для ситуаций, когда возможен недостаток портов, рекомендуется немного
увеличить net.inet.ip.portrange.last
. Может подойти
значение 10000, 20000, или 30000. Учтите также возможное влияние брандмауэра при
изменении диапазона портов. Некоторые могут блокировать большие диапазоны портов
(обычно с небольшими номерами) и вынуждают использовать более высокие диапазоны для
исходящих соединений. По этой причине не рекомендуется уменьшать значение
net.inet.ip.portrange.first
.
TCP Bandwidth Delay Product Limiting похоже на TCP/Vegas в NetBSD. Оно может
быть включено установкой переменной sysctl net.inet.tcp.inflight.enable
в 1.
Система попытается вычислить задержку пакетов для каждого соединения и ограничить
объем данных в очереди сети до значения, требуемого для поддержания оптимальной
пропускной способности.
Эта возможность полезна при передаче данных через модемы, Gigabit Ethernet, или
даже через высокоскоростные WAN соединения (или любые другие соединения с большой
задержкой передачи), особенно если вы также используете изменение размера окна или
настроили большое окно передачи. Если вы включили этот параметр, убедитесь
также, что переменная net.inet.tcp.inflight.debug
установлена в 0 (отладка выключена), а для использования в
реальных задачах может понадобиться установка переменной net.inet.tcp.inflight.min
к значению как минимум 6144. Но учтите, что установка большого значения этой
переменной может фактически отключить ограничение в зависимости от вида соединения.
Ограничение уменьшает количество данных на определенном маршруте и управляет
очередью пакетов, как и уменьшает общее количество данных в очереди локального
интерфейса хоста. С меньшим количеством пакетов в очереди двусторонние
интерактивные соединения, особенно на медленных линиях, могут проходить
быстрее. Но имейте ввиду, что эта функция работает только при передаче данных
(передача данных / сторона сервера). Она не работает при получении данных
(загрузке).
Изменение значения переменной net.inet.tcp.inflight.stab
не рекомендуется. Этот параметр по умолчанию равен 20,
что означает добавление 2 пакетов к вычислению задержки передачи. Дополнительное
окно требуется для стабилизации алгоритма и улучшения ответной реакции на изменение
условий, но также приводит к большему времени ping на медленных соединениях
(задержка все же гораздо меньше, чем без алгоритма inflight). Вы можете попробовать
уменьшить этот параметр до 15, 10 или 5; а также уменьшить net.inet.tcp.inflight.min
(например, до 3500) для получения
желаемого эффекта. Уменьшение значений этих параметров может использоваться только
как крайняя мера.
kern.maxvnodes
Файлы и каталоги в ядре представлены при помощи vnode (виртуальных узлов). Увеличение их числа может помочь уменьшить нагрузку на дисковую подсистему. Как правило, специальной настройки это значение не требует, однако, в некоторых случаях дисковая активность является узким местом, и система исчерпывает таблицу vnode, значение этой переменной следует увеличить. При этом необходимо оценить объем неактивной и свободной памяти.
Текущее количество использованных vnode можно посмотреть при помощи команды:
# sysctl vfs.numvnodes vfs.numvnodes: 91349
Максимальное количество vnode, доступных системе:
# sysctl kern.maxvnodes kern.maxvnodes: 100000
Если количество использованных vnode близко к максимуму, значение переменной
kern.maxvnodes
следует увеличить на 1000. Следите за
динамикой изменения vfs.numvnodes
. Если оно
увеличивается, приближаясь к вновь установленному максимуму, процесс следует
повторить. Изменение в распределении памяти должно быть видно в выводе утилиты top(1): больше памяти
перейдет в разряд активной.
[1] |
Алгоритм автоматической настройки установит maxusers равным количеству памяти в системе, где минимум 32, а максимум 384. |
Пред. | Начало | След. |
Оптимизация дисков | Уровень выше | Увеличение объема подкачки |
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <[email protected]>.
По вопросам, связанным с этой документацией, пишите <[email protected]>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <[email protected]>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.