Тюнинг FreeBSD 7
2009-05-31 15:39![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Видеозапись лекции Игоря Сысоева по настройке некоторых подсистем FreeBSD 7 (44 минуты 30 секунд).
(Update: см. также http://www.opennet.ru/base/net/tune_freebsd.txt.html)
Квинтэссенция:
- открытый TCP-сокет суммарно потребляет порядка 1800 байт в ядре и, выставляя sysctl kern.ipc.maxsockets=100000, мы позволяем ядру занять более 170Mb только под хранение информации об открытых сокетах;
количество открытых в данный момент сокетов можно посмотреть в sysctl kern.ipc.numopensockets;
- поиск сокета по входящему пакету хешированный с размером хеш-таблицы, изменяемой через /boot/loader.conf параметром net.inet.tcp.tcbhashsize; по умолчанию 512 записей, можно увеличить до 32K для ускорения поиска;
- очередь установленных TCP-коннектов, ещё не принятых (accept) приложением, имеет размер sysctl kern.ipc.somaxconn (128 по умолчанию); netstat -Lan показывает список этих очередей, включая степень их заполненности;
- принятый TCP-коннект порождает дескриптор открытого файла, который потребляет 128 байт (итого более 190Mb на 100000 коннектов с учетом 170Mb на сокеты);
общее количество открытых файлов в системе ограничивает sysctl kern.maxfiles, а текущее показывает sysctl kern.openfiles;
плюс имеется ограничение на количество открытых файлов на процесс sysctl kern.maxfilesperproc;
плюс могут быть ещё ограничения в самом приложении (а также внутренний расход памяти приложения на каждый файл);
- данные, приходящие из сети в сокет, попадают в ядерные буфера mbuf (256 байт) и mbuf cluster (2Kb) (связный набор буферов mbuf, в сумме хранящий все данные пакета);
выставляя sysctl kern.ipc.nmbclusters=100000, разрешаем ядру использовать под эти буфера дополнительно более 207Mb (2048+256 байт на каждый кластер и прилагающийся с нему дополнительный служебный mbuf);
- в один сокет может прийти до sysctl net.inet.tcp.recvspace данных, не принятых ещё приложением - они потребляют упомянутые выше буфера;
в FreeBSD 7 есть (отключаемый) механизм автоувеличения этого параметра (sysctl net.inet.tcp.recvbuf_auto, описание см. ниже на примере net.inet.tcp.sendbuf_auto);
- начиная с FreeBSD 7 отправляемые приложением в сеть данные потребляют mbuf и mbuf clusters размером по странице (4K для i386) и не используют двухкилобайтные nmbclusters (см. выше);
количество четырехкилобайтных кластеров, используемых для отправки, ограничивается через sysctl kern.ipc.nmbjumbop, по умолчанию 12800; на 100000 их потребуется более 488Mb ядерной памяти (128+4096 байт на каждый);
- исходящие данные одного сокета могут занять в ядерной памяти до sysctl net.inet.tcp.sendspace байт и при медленно принимающих клиентах и неправильных настройках этого параметра и kern.ipc.nmbjumbop буфера на отправку могут исчерпаться (медленные клиенты могут устроить DoS), причем в FreeBSD 7 по умолчанию включено автоувеличение этого буфера для быстрых клиентов (sysctl net.inet.tcp.sendbuf_auto=1), но до обрыва соединения невозможно освободить выросший буфер, если быстрый клиент вдруг прекратит приём;
автоинкремент идет порциями по net.inet.tcp.sendbuf_inc, максимальный размер буфера задаёт net.inet.tcp.sendbuf_max;
- закрытое сервером соединение ожидает подтверждения закрытия от клиента, потребляя меньше памяти, чем открытое;
таких соединений может быть до sysctl net.inet.tcp.maxtcptw (часть от kern.ipc.maxsockets, поэтому такие сокеты мешают открытию новых);
однако, если приложение не предпринимает специальных мер (ограничение linger-таймаута), то после закрытия сокета довольно длительное время буфера могут оставаться занятыми данными, для которых не было получено подтверждения приёма от клиента;
- начиная с версии 7.2/amd64 размер ядерной памяти по умолчанию равен четверти физической памяти, но не более 3.6Gb (ранее предел был чуть более 1.5Gb);
этот размер можно увеличить до двух размеров физической памяти в /boot/loader.conf параметром vm.kmem_size, например: vm.kmem_size=3G
- максимальный размер файлового кеша ограничивается лимитом на количество кешируемых файлов sysctl kern.maxvnodes (не более 100000 по умолчанию) и при большом объеме памяти и недостаточном значении kern.maxvnodes память может не использоваться эффективно под кеш, если файлы мелкие и их очень много;
- пакеты, приходящие через драйвер сетевой карты, могут обрабатываться сразу при sysctl net.isr.direct=1, либо сначала укладываться в очередь при нулевом значении этого параметра;
размер очереди задаётся через sysctl net.inet.ip.intr_queue_maxlen (можно поставить и 2048, и 4096); при использовании очереди и её переполнении пакет выкидывается;
- top -S показывает потребление процессора системными тредами и при net.isr.direct=0 можно увидеть отдельно процент процессорного времени, затрачиваемый на обработку пакетов сетевым стеком уже без участия драйвера сетевой карты - при включенной очереди вся обработка выполняется одним тредом и не распараллеливается; (информация устарела - начиная с 8.0-RELEASE, обработка очереди по умолчанию распараллеливается на все ядра системы и степенью параллелизма можно управлять через loader.conf)
распараллеливание можно получить, отключив очередь и принимая трафик несколькими сетевыми картами; (информация устарела - см. выше)
файрволы (пакетные фильтры) мешают параллельной обработке пакетов своими блокировками на этапе проверки правил;
- установка sysctl kern.ipc.shm_use_phys=1 при использовании приложений, активно потребляющих SYSV Shared Memory (СУБД), экономит ядерную память и запрещает вытеснение такой разделяемой памяти в своп;
- использование версии 7.2 позволяет использовать сегменты разделяемой памяти SYSV размером более 2Gb и автоматически (прозрачно для приложений) использовать 4-мегабайтные страницы вместо 4-килобайтных, уменьшая размер системных таблиц и количество промахов процессорного кеша, увеличивая таким образом общее быстродействие системы.
рулес (-)
Date: 2009-05-31 12:08 (UTC)no subject
Date: 2009-05-31 12:26 (UTC)no subject
Date: 2009-06-01 07:52 (UTC)*А если немного обнаглеть*
Date: 2009-06-01 08:27 (UTC)Re: *А если немного обнаглеть*
Date: 2009-06-01 08:45 (UTC)Re: *А если немного обнаглеть*
Date: 2009-06-01 08:47 (UTC)Если не обломаюсь - сяду вечером стенограмму делать
Re: *А если немного обнаглеть*
Date: 2009-06-01 12:39 (UTC)Re: *А если немного обнаглеть*
Date: 2009-06-01 16:45 (UTC)Лично мне более удобно читать справочник, чем стенограмму живого голоса.
no subject
Date: 2009-06-02 14:41 (UTC)Я читал про Ваши эксперименты с генерируемым исходящего потоком трафика в RU.UNIX.BSD и результах которые вы достигли. Ну в общем и занимаюсь тем же, не знаю мне кажется мне удалось добиться несколько больших результов:
На интерфейсе:
packets errs bytes packets errs bytes colls
1259248 0 75554880 0 0 0 0
1258310 0 75498600 0 0 0 0
1256251 0 75375060 0 0 0 0
1257109 0 75426480 0 0 0 0
1258555 0 75513360 0 0 0 0
1256815 0 75408900 0 0 0 0
Ну и собственно вопрос:
74 processes: 5 running, 53 sleeping, 16 waiting
CPU states: 0.0% user, 0.0% nice, 10.7% system, 0.2% interrupt, 89.1% idle
Mem: 19M Active, 165M Inact, 275M Wired, 12K Cache, 214M Buf, 3457M Free
Swap: 2048M Total, 2048M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
12 root 171 ki31 0K 16K CPU2 2 255.4H 100.00% idle: cpu2
13 root 171 ki31 0K 16K RUN 1 253.3H 100.00% idle: cpu1
14 root 171 ki31 0K 16K CPU0 0 252.9H 100.00% idle: cpu0
11 root 171 ki31 0K 16K CPU3 3 177.9H 67.09% idle: cpu3
27 root -68 - 0K 16K - 3 75.0H 35.50% em2 taskq
15 root -44 - 0K 16K WAIT 3 18.9H 2.29% swi1: net
Откуда берется 2.29% swi1: net ? Это я так понимаю как раз и есть случай "файрволы (пакетные фильтры) мешают параллельной обработке пакетов своими блокировками на этапе проверки правил;".
P.S> Сумбурно получилось - пишу сюда потому, что не получается подписаться на RU.UNIX.BSD.
no subject
Date: 2009-06-02 14:55 (UTC)no subject
Date: 2009-06-02 15:04 (UTC)# 1. Network perfomance tunning
# 1.1 Packet forwarding
# 1.1.1 Enable packet forwarding between ifaces
# Enable in rc.conf by option gateway_enable="YES"
# net.inet.ip.forwarding=1
# 1.1.2 Enable flow-based IP forwarding (analog ip cef in Cisco IOS)
net.inet.ip.fastforwarding=1
# 1.1.3 Increase the number of network mbufs (~70Mb phys. memory)
# Use netstat -m for monitoring
kern.ipc.nmbclusters=32768
# 1.1.4 Size of the listen queue for accepting new TCP connections
# Use netstat -Lan for monitoring
kern.ipc.somaxconn=4096
kern.ipc.maxsockets=204800
# 1.1.5 Other network buffering (local network-intensive application)
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
# 1.2 Protocol spec. options
# 1.2.1 Disable sending IP redirects (ICMP_REDIRECT)
net.inet.ip.redirect=0
net.inet.icmp.drop_redirect=1
# 1.2.2 Drop SYN without RST on closed ports
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
# 1.2.3 Maximum size of the IP input queue
# Need much more on Gigabit Ethernet Connections (tune em-iface in loader.conf to use it)
net.inet.ip.intr_queue_maxlen=5120
# 1.2.4 Disable forwarding packets without touching the TTL
# net.inet.ip.stealth=0
# 1.2.5 Drop SYNFIN packets enable in rc.conf (needs option in kernel on 6.x)
# 1.3 Dummynet settings
# 1.3.1 Enable fast dummynet operation mode (needs FreeBSD 7.1 and above)
# net.inet.ip.dummynet.io_fast=1
# 1.3.2 Will paccket exit from IPFW after dummynet/netgraph/pf?
# net.inet.ip.fw.one_pass=0
# 1.3.3 Default size of the hash table used for dynamic pipes/queues.
net.inet.ip.dummynet.hash_size=512
# 1.3.4 Target value for the maximum number of pipes/queues in a hash bucket.
net.inet.ip.dummynet.max_chain_len=32
# 1.3.5 The number of buckets in the hash table for dynamic(keep-state) rules.
net.inet.ip.fw.dyn_buckets=1024
# 1.4 Netgraph setting
net.graph.recvspace=40960
net.graph.maxdgram=40960
# 2. Hardware perfomance tunning
# 2.1 Using delayed interrupts on em(4) ifaces - use carefully
# Default values
# dev.em.2.rx_int_delay: 0
# dev.em.2.tx_int_delay: 66
# dev.em.2.rx_abs_int_delay: 66
# dev.em.2.tx_abs_int_delay: 66
# Current values:
dev.em.0.rx_int_delay=600
dev.em.0.tx_int_delay=600
dev.em.0.rx_abs_int_delay=1000
dev.em.0.tx_abs_int_delay=1000
dev.em.0.rx_processing_limit=1024
...
А использование netgraph никак не может влиять на рост данного параметра, то есть не будет ли рости этот параметр из-за использования связки "прослойки" ng_ipfw?
У меня ~540 нод ng_car для шейпинга абонентов.
P.S> За английский простите :)
no subject
Date: 2009-06-02 15:09 (UTC)net.isr.swi_count: -797094106
net.isr.drop: 0
net.isr.queued: 163443
net.isr.deferred: 0
net.isr.directed: 176141967
net.isr.count: 176141959
net.isr.direct: 1
Это я так и понимаю: 2.29% swi1: net - net.isr.queued: 163443
no subject
Date: 2009-06-02 15:40 (UTC)Всё зависит от того, что именно делает машина - принимает трафик или посылает
или и то и другое?
no subject
Date: 2009-07-28 13:02 (UTC)no subject
Date: 2009-07-28 13:43 (UTC)no subject
Date: 2009-07-28 14:17 (UTC)От использования драйверов Yandex у меня отрицательные впечатления - по крайней мере в стенде они себя не оправдывают, в случае количесва сет. карт от 2-х и выше. Возможно в моем случае подойдет - но я думаю поможет несильно, да и единообразность настройки, имхо, лучше.
Есть 'правильно' настроенная машина c родными драйверами, но правда с несколько иными функциями - она в порядке:
CPU: 0.0% user, 0.0% nice, 30.0% system, 0.4% interrupt, 69.6% idle
Mem: 432M Active, 685M Inact, 548M Wired, 156K Cache, 399M Buf, 2250M Free
Swap: 1024M Total, 1024M Free
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 171 ki31 0K 16K RUN 3 994.3H 85.60% idle: cpu3
13 root 171 ki31 0K 16K RUN 1 984.1H 80.37% idle: cpu1
14 root 171 ki31 0K 16K CPU0 0 981.1H 78.56% idle: cpu0
12 root 171 ki31 0K 16K RUN 2 802.4H 53.17% idle: cpu2
31 root -68 - 0K 16K CPU2 2 339.1H 51.37% em2 taskq
33 root -68 - 0K 16K - 0 154.2H 26.95% em4 taskq
34 root -68 - 0K 16K CPU1 1 153.8H 21.97% em5 taskq
32 root -68 - 0K 16K - 3 139.7H 17.19% em3 taskq
15 root -32 - 0K 16K WAIT 1 17.2H 0.49% swi4: clock sio
net.isr.swi_count: 40801772
net.isr.drop: 0
net.isr.queued: 41559024
net.isr.deferred: 0
net.isr.directed: 40648743
net.isr.count: 40648742
net.isr.direct: 1
# netstat -w 1
input (Total) output
packets errs bytes packets errs bytes colls
336151 0 205622988 335536 0 205053358 0
337728 0 206998536 337279 0 206625688 0
329848 0 200951412 328862 0 200116493 0
333128 0 203149614 333129 0 203107032 0
324422 0 197433838 324357 0 197252086 0
329102 0 201636336 328756 0 201333488 0
334167 0 202873333 333843 0 202485757 0
329318 0 199838171 329384 0 199766041 0
326482 0 198568800 326565 0 198560830 0
С запасом заменяет Сisco7507.
Спасибо Вам за разъяснения.
no subject
Date: 2009-07-21 12:12 (UTC)А в чём проблема?
no subject
Date: 2009-07-28 13:01 (UTC)no subject
Date: 2009-07-28 13:24 (UTC)А для публичных серверов автоматическая регистрация запрещена.
Что не мешает написать по известному адресу просьбу о ручной.
no subject
Date: 2009-07-28 14:06 (UTC)И 'ручную' регистрацию тоже просил - до сих пор жду ответа.
Ладно не критично - тем более в свете происходящих там 'словесных баталий' последнее время:)
no subject
Date: 2009-07-30 06:16 (UTC)http://news.cca.usart.ru
http://www.fido7.ru
Ни один не подходит?
no subject
Date: 2009-07-30 08:53 (UTC)Собственно, я подписан на 'получение новостей' от туда, но он видимо лежит, как Вы уже заметили.
no subject
Date: 2009-07-30 06:34 (UTC)no subject
Date: 2011-06-08 08:51 (UTC)Можно поподробнее?
no subject
Date: 2011-06-08 16:37 (UTC)no subject
Date: 2011-06-08 17:39 (UTC)net.isr.maxthreads: 1
пойду крутить, спасибо