dadv: (chuck)
[personal profile] dadv

Видеозапись лекции Игоря Сысоева по настройке некоторых подсистем 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)

Date: 2009-05-31 12:26 (UTC)
From: [identity profile] logger.livejournal.com
Хотя многое уже известно, но все равно хороший FAQ.

Date: 2009-06-01 07:52 (UTC)
From: [identity profile] l2tp.livejournal.com
Спасибо. Очень вовремя нашлось :)
From: [identity profile] l2tp.livejournal.com
... и спросить - есть ли записи выступлений в текстовом виде? Видео на полях комментировать для себя неудобно
From: [identity profile] dadv.livejournal.com
Был бы текст доклада - я бы не тратил время на этот пост.
From: [identity profile] l2tp.livejournal.com
Жалька.

Если не обломаюсь - сяду вечером стенограмму делать
From: [identity profile] l2tp.livejournal.com
http://l2tp.livejournal.com/80191.html - Первые 16 минут, больше пока не успела. Если интересно, конечно :)
From: [identity profile] dadv.livejournal.com
Ну, я-то видео смотрел :-)
Лично мне более удобно читать справочник, чем стенограмму живого голоса.

Date: 2009-06-02 14:41 (UTC)
From: [identity profile] sa-drug.livejournal.com
А у меня давно зрел вопрос.
Я читал про Ваши эксперименты с генерируемым исходящего потоком трафика в 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.

Date: 2009-06-02 14:55 (UTC)
From: [identity profile] dadv.livejournal.com
Ответ на этот вопрос содержится, скорее всего, в выводе sysctl net.isr - об этом говорил и Игорь Сысоев в своём докладе и написано у меня. Даже если у вас по дефолту net.isr.direct=1, в некотором небольшом проценте случаев очередь всё-таки используется (для исключения вероятности бесконечной рекурсии внутри ядра, например). Обработка стеком пакетов из очереди выполняется тредом swi1.

Date: 2009-06-02 15:04 (UTC)
From: [identity profile] sa-drug.livejournal.com
Да у меня дефолтное значение этого параметра net.isr.direct=1.
# 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> За английский простите :)

Date: 2009-06-02 15:09 (UTC)
From: [identity profile] sa-drug.livejournal.com
Сначала написал, затем понял, что Вы имели в виду.
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

Date: 2009-06-02 15:40 (UTC)
From: [identity profile] dadv.livejournal.com
Значение net.isr.queued маловато, так что не только на эти пакеты время тратилось.
Всё зависит от того, что именно делает машина - принимает трафик или посылает
или и то и другое?

Date: 2009-07-28 13:02 (UTC)
From: [identity profile] sa-drug.livejournal.com
И то и другое в самой ужасной возможной конфигурации - трафик приходт и уходит дальше по одному vlan-у.

Date: 2009-07-28 13:43 (UTC)
From: [identity profile] dadv.livejournal.com
Так как счетчики, судя по отрицательным значением, у вас переполняются, малое значение net.isr.queued не может быть доказательством малого использования очереди - нужно смотреть скорость роста этого значения в динамике, это во-первых. Ну и во-вторых, да, при входящем/исходящем трафике внутри одного vlan стандартный драйвер em параллелизма не добавляет - надо пробовать яндексовский.

Date: 2009-07-28 14:17 (UTC)
From: [identity profile] sa-drug.livejournal.com
Проще сделать еще один vlan через другой физический интерфейс - я это прекрасно понимаю, но вот руководство 'менять схему' не намеряно. Что ж, я подожду пока снова все упадет, тем более с козырем на руках :)

От использования драйверов 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.

Спасибо Вам за разъяснения.

Date: 2009-07-21 12:12 (UTC)
From: [identity profile] andy-demos-su.livejournal.com
> P.S> Сумбурно получилось - пишу сюда потому, что не получается подписаться на RU.UNIX.BSD.

А в чём проблема?

Date: 2009-07-28 13:01 (UTC)
From: [identity profile] sa-drug.livejournal.com
Ну почему-то, например для ящиков с домена vlgmail.ru невозможно оформить подписку.

Date: 2009-07-28 13:24 (UTC)
From: [identity profile] andy-demos-su.livejournal.com
Наверное, потому что они подпадают под маску *mail.ru :-))
А для публичных серверов автоматическая регистрация запрещена.
Что не мешает написать по известному адресу просьбу о ручной.

Date: 2009-07-28 14:06 (UTC)
From: [identity profile] sa-drug.livejournal.com
Да пробывал я и так и ... по всякому короче пробовал. Например, с vgg.ru - также отказ.
И 'ручную' регистрацию тоже просил - до сих пор жду ответа.
Ладно не критично - тем более в свете происходящих там 'словесных баталий' последнее время:)

Date: 2009-07-30 06:16 (UTC)
From: [identity profile] redrat.livejournal.com
http://f75.n5004.z2.fidonet.net
http://news.cca.usart.ru
http://www.fido7.ru

Ни один не подходит?

Date: 2009-07-30 08:53 (UTC)
From: [identity profile] sa-drug.livejournal.com
В настоящий момент мне наиболее удобно рабоать с news3.fido7.ru.
Собственно, я подписан на 'получение новостей' от туда, но он видимо лежит, как Вы уже заметили.

Date: 2009-07-30 06:34 (UTC)
From: [identity profile] redrat.livejournal.com
Упс, два верхних уже не отвечают. Хотя я через них работал. Увы... :-(

Date: 2011-06-08 08:51 (UTC)
From: [identity profile] denis-sotchenko.livejournal.com
"степенью параллелизма можно управлять через loader.conf"
Можно поподробнее?

Date: 2011-06-08 16:37 (UTC)
From: [identity profile] dadv.livejournal.com
net.isr.maxthreads задаёт количество ядерных тредов, параллельно разгребающих очередь netisr. По умолчанию (оно же максимум) - количество процессорных ядер в системе, можно задать меньше.

Date: 2011-06-08 17:39 (UTC)
From: [identity profile] denis-sotchenko.livejournal.com
кхм…
net.isr.maxthreads: 1
пойду крутить, спасибо

Profile

dadv: (Default)
Choose your future

July 2024

M T W T F S S
12 34567
891011121314
15161718192021
22232425262728
293031    

Tags

Style Credit

Powered by Dreamwidth Studios