Sysctl в Freebsd

Вот собственно если ты это ввел в поиске значит ты сталкнулся с проблемой ,  при которой стандартные значения systcl  тебя уже не устраивают . Сразу хочу сказать , что без повода sysctl как и ядро системы трогать нет смысла …. в 80 % случаях с которыми я сталкивался.

Sysctl — это системный вызов изменяемый параметры ядра .

В FreeBSD версии 6.1 доступно более тысячи переменных, разбитых на 12 основных разделов:

Корневые ветви дерева MIB

kern — основные настройки ядра;

vm — подсистема виртуальной памяти;

vfs — подсистема VFS;

net — стек сетевых протоколов;

debug — отладочная информация;

hw — настройки аппаратного обеспечения;

machdep — настройки, зависящие от аппаратной платформы;

user — ограничения пользователей;

p1003_1b — совместимость со стандартом POSIX 1003.1b;

compat — совместимость с другими операционными системами;

security – безопасность;

dev — информация об аппаратных устройствах.

# sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'

вывод:

hw.machine: i386
hw.model: Intel(R) Pentium(R) Dual  CPU  E2160  @ 1.80GHz
hw.ncpu: 2
hw.machine_arch: i386

Или аналог данной команды

grep -i cpu /var/run/dmesg.boot

вывод:

CPU: Intel(R) Pentium(R) Dual  CPU  E2160  @ 1.80GHz (1795.51-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
p4tcc1: <CPU Frequency Thermal Control> on cpu1
SMP: AP CPU #1 Launched!

Если сервер сильно нагружен сетевой подсистемой , тогда рекомендуют делать так :

Примеры

2 ядра + 2 сетевые intel (em, драйвера правильные, с разделением предобработки в обработчике прерывания и последующего процессинга отдельном потоке)

net.isr.direct=1
net.isr.direct_arp=1
net.isr.maxthreads=1
net.inet.ip.fastforwarding=0
net.inet.ip.dummynet.io_fast=1

8 ядрер + 2 сетевые broadcom (bge, какие-то неправильные 😉

net.isr.direct=0
net.isr.direct_arp=1
net.isr.maxthreads=5
net.inet.ip.fastforwarding=0
net.inet.ip.dummynet.io_fast=1

Немного подробнее о каждом из них:

  • net.isr.direct — обрабатывать исходящие пакеты непосредственно при попытке отправки (в т.ч. прохождение ipfw на выходе). Т.е. не откладывать в очередь, которую в отдельном потоке разгребает netisr. Есть смысл включать, если количество ядер меньше или равно количеству сетевых карточек. Влияет на скорость ОТПРАВКИ пакетов. Для серверов это хорошо, для роутеров — не очень. Если нагрузка на сетевые карты неравномерная, или когда есть хотя бы одно хронически недогруженое ядро — выключать.
    При включеном net.inet.ip.fastforwarding будет еще 1 спецэффект.
  • net.isr.direct_arp — обрабатывать исходящие ARP пакеты непосредственно при попытке отправки. Есть смысл держать включенным в большинстве случаев (разумного варианта, когда стоит отправлять такие запросы в очередь я придумать не могу). Добавлено для того, чтобы обработкой ARP система могла заниматься с бОльшим приоритетом даже при net.isr.direct=0
  • net.isr.maxthreads — собственно, количество потоков, разгребающих очередь пакетов. Есть смысл ставить меньшим количества ядер в системе. Нужно прикинуть, сколько ресурсов съедается на обработке прерываний от сетевух и не только, сколько в пике потребляет прочий софт (БД, httpd, прочие демоны) и на оставшееся распределить роутинг. Если, к примеру, сетевухи потребляют по 80% с 2х ядер и софт еще до 100% одного ядра, а всего ядер 4, то остается 140% гарантированного времени. Т.е. полтора ядра 😉 Тут можно смело ставить роутинг в 2 потока. Если нагрузки по софту кратковременные, а на роутинг с трудом хватает — можно даже попробовать 3.
  • net.inet.ip.fastforwarding — обрабатывать входящие пакеты непосредственно в момент приема (в т.ч. прохождение ipfw на входе, до попадания в очередь netisr). Есть смысл включать, если количество ядер меньше или равно количеству сетевых карточек, так же как и net.isr.direct. Влияет на скорость ПРИЕМА пакетов. Обработка пакета происходит прямо в обработчике прерывания. Следует учесть, что не все сетевухи и не все драйвера нормально умеют складировать новые пакеты в очередь, пока обрабатывается текущий. При включеном net.inet.ip.fastforwarding будет еще 1 спецэффект — маршрутизация пакета и прохождение ipfw (оба раза) будут происходить в том же обработчике прерывания. Фактически, на время обработки входящего пакета сетевая карта будет заблокирована. Это неплохо смотрится при преобладающем входящем трафике и на однопроцессорных машинах.
  • net.inet.ip.dummynet.io_fast — если трафик помещается в заданную полосу, не пропускать его через очередь и отдельный поток. Если нет необходимости эмулировать задержки и потери в канале — очень сильно сохраняет ресурсы. При использовании этой опции практически отпадает необходимость в распараллеливании dummynet, хотя этот патчик (а также аналогичный патч для nat’а я сделать все еще планирую).
  • net.inet.ip.intr_queue_maxlen, net.route.netisr_maxqlen — фактически — размеры входящей и исходящей очередей. При большой нагрузке в режиме маршрутизации есть смысл увеличивать эти значения. Непоместившийся пакет выбрасывается. Это условно спасет при кратковременных перегрузках (часть пакетов пролетит с большой задержкой) но совершенно не спасет при хронических.