Вопрос к гуру по FreeBSD (polling, dummynet)

[networks]

Здравствуйте!

 

Ситуация: маршрутизатор, FreeBSD 6.3, P4 3.0GHz, 1024MB RAM, карточка Intel PRO-1000 (em)

 

Служит шлюзом в Интернет, на нем NAT (через ipnat), и шейперы для абонентов-анлимщиков (через ipfw dummynet).

 

Правила ipfw создаются при соединении каждого анлимщика индивидуально:

 

ipfw add (num) pipe (num) ip from any to X.X.X.X out via vlanX

ipfw add (num+1) pipe (num+1) ip from X.X.X.X to any in via vlanX

 

ipfw pipe (num) config bw (speed)Kbit/s delay 0ms

ipfw pipe (num+1) config bw (speed)Kbit/s delay 0ms

 

Где X.X.X.X - ip-адрес, выдаваемый алнимщику при соединении с VPN-сервером (отдельная машина, PPTP), и vlanX - интерфейс, смотрящий на VPN-сервер.

 

Также на этом маршрутизаторе включен polling. Параметры polling:

 

options HZ=2000

kern.polling.user_frac=20

kern.polling.burst_max=300

 

 

Суть проблемы - постоянное увеличение kern.polling.lost_polls (по 100-500 в секунду), постоянно скачет параметр kern.polling.burst (от 10 до 300). При этом по выводу top показывается загрузка user, system, interrupt (по 20-30%).

 

PPS через em0 совсем небольшой - в пределах 20-25 Kpps.

 

При этом маршрутизатор уже 3 раза самопроизвольно перезагружался. Поменяли железо в субботу полностью, но сегодня вечером он опять перезагрузился.

 

Ну и, собственно, Интернет подтормаживает. Странички грузятся рывками, как будто где-то застревают, а потом мигом пролетают к клиенту.

 

Догадываюсь, что lost_polls означает, что пакеты не успевают обрабатываться во время poll-а, и следующие poll-ы теряются. Вопрос только - почему они не успевают? Может быть, dummynet не совместим с polling, и лучше его выключить? Он был включен ранее, когда на этот маршрутизатор была бОльшая нагрузка в Kpps (порядка 150-200). Или дело не в этом, а в количестве правил dummynet? Их (групп по 4 правила) создается до 120-130 штук (по мере соединения анлимщиков).

 

В общем, завтра собираюсь попробовать выключить polling, если это не поможет - даже не знаю, куда еще кинуться. Может, подскажете чего?

Edited September 15, 2008 by networks

[networks]

Почитал форум, увидел, что эффективнее создать несколько пайпов, и раскидать по ним клиентов таблицами, чем создавать отдельный пайп на каждого клиента. Это можно сделать, но, может быть, в моем случае проблема не в этом? Пайпов то вроде немного, в пределах 200 штук (в одну сторону).

Edited September 15, 2008 by networks

[Skylord]

Ты правильно насчет dummynet'а подумал. Он у меня примерно с таким же трафиком ни фига с polling'ом не сочетается: загрузка процессора небольшая, но потери, низкая скорость и т.п. При отключении поллинга все нормально, пока не начинается ЧНН: прерывания уходят "в высь" несмотря на тюнинг em. Вопрос на данный момент решил выставлением net.isr.direct="0" - производительность будет не топовая, но зато в жесткий загруз уходить не будет и в целом - работа удовлетворительная. После выхода релиза 7.1 буду со всем этим хозяйством экспериментировать заново - в 7-stable закоммитили интересный патч в dummynet - нужно будет обязательно попробовать - есть мнение, что существенно скажется на производительности в лучшую сторону. :-)

В данный конкретный момент рекомендую в любом случае тоже перейти на седьмую ветку - она с шедулером ULE все-таки сильно лучше нагрузку по процам распределяет - есть реальный толк от SMP на роутере-нате-шейпере. Правила, естесствено, распихать по таблицам: будет и эстетичнее, и удобнее работать, и при использовании tablearg трафик шейпится вообще двумя строчками (одной в одну сторону, а другой - в другую). И поставь сетевушки pcie - самые дешевые Интелы стоят буквально 1000 руб., а количество innerrupt'ов лично у меня тут же сбросили на 10%. :-)

[Maxa]

Вообще для em ставить HZ больше 1000 не стоит, как раз таки для того, чтобы не было дропов. А еще лучше попробовать выключить поллинг и использовать FAST_INT (алгоритм обработки для em, если правильно помню то, что в последний раз было видно в сырцах - включается автоматически при включении поллинга).

 

Да, 130*4=520 правил - совсем не нагрузка для такого роутера, как у вас :)

[networks]

Выключил polling, особой разницы не почувствовал. Увеличил net.inet.ip.intr_queue_maxlen до 256 (было 50). Копаю дальше.

 

Попробую вернуться на HZ=1000 (поставил 2000 совсем недавно, как раз когда эта проблема начала беспокоить).

 

net.isr.direct кстати, так и так стоит 0, по умолчанию.

Edited September 16, 2008 by networks

[Maxa]

Выключил polling, особой разницы не почувствовал. Увеличил net.inet.ip.intr_queue_maxlen до 256 (было 50). Копаю дальше.

 

Попробую вернуться на HZ=1000 (поставил 2000 совсем недавно, как раз когда эта проблема начала беспокоить).

 

net.isr.direct кстати, так и так стоит 0, по умолчанию.

Есть аналогичный роутер:

CPU: Intel(R) Xeon(R) CPU            3075  @ 2.66GHz (2660.01-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFL
USH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xe3fd<SSE3,RSVD2,MON,DS_CPL,VMX,<b6>,EST,TM2,<b9>,CX16,<b14>,<b15>>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 1072103424 (1022 MB)
avail memory = 1044336640 (995 MB)

С немного бОльшей нагрузкой по траффику, сравним количеством правил в файерволле и двумя "набортными" em.

polling отключен.

FreeBSD 6.2-RELEASE #0: Wed Feb 27 11:11:06 EET 2008 
last pid: 18978;  load averages:  1.00,  1.00,  1.00                                                                                                      up 25+23:04:44  11:47:37
36 processes:  1 running, 35 sleeping
CPU states:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle

NAT-а, правда, нет, но есть другие задачи. И "баловства" такого тоже нет.

 

P.S. А причину перезагрузки сампроизвольной уже установили?

[networks]

Причину перезагрузки пока не установил.

У меня на этом роутере: некоторое количество vlan на em0 (в т.ч. и Интернет), dhcpd, ipcad, zebra (только RIP), ipnat+порядка 50 правил ipf, ну и dummynet + ipfw - то что я писал.

 

По top -S сейчас:

 

10 root 1 171 52 0K 8K RUN 731:43 40.43% idle

11 root 1 -44 -163 0K 8K WAIT 284:34 27.49% swi1: net

21 root 1 -68 -187 0K 8K WAIT 12:57 10.45% irq17: em0

 

 

Сейчас хочу попробовать поставить драйвера на em от yandex.

Edited September 16, 2008 by networks

[Maxa]

Причину перезагрузки пока не установил.

У меня на этом роутере: некоторое количество vlan на em0 (в т.ч. и Интернет), dhcpd, ipcad, zebra (только RIP), ipnat+порядка 50 правил ipf, ну и dummynet + ipfw - то что я писал.

 

По top -S сейчас:

 

10 root 1 171 52 0K 8K RUN 731:43 40.43% idle

11 root 1 -44 -163 0K 8K WAIT 284:34 27.49% swi1: net

21 root 1 -68 -187 0K 8K WAIT 12:57 10.45% irq17: em0

 

 

Сейчас хочу попробовать поставить драйвера на em от yandex.

netstat -I em0 можно посмотреть?

[networks]

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

em0 1500 <Link#1> 00:07:e9:0a:1b:4d 671723009 257 667774861 0 0

 

[madw]

попробуй

kern.polling.idle_poll: 1

[Skylord]

Да не при чем тут polling - чего вы его мучаете... Достаточно убрать dummynet и все просто летать будет и затыки все исчезнут. У меня так и было.

Почему нет желания на семерку обновиться? Уж по любому от ULE хуже не станет...

[networks]

Собрал дрова от яндекса в ядро, вечерком ребутнусь, посмотрю, как будет.

 

Skylord: если ничего не поможет, будут до 7-ки обновляться. Просто не уверен, что всё остальное не поломается в процессе :)

 

kern.polling.idle_poll ставить пробовал, нагрузка еще больше возрастает.

Edited September 16, 2008 by networks

[ingress]

дрова от яндекса вешают всё :(

 

упоминание здесь: http://community.livejournal.com/ru_root/1561283.html

 

у меня аналогично.

[networks]

Кстати, интересный вывод netstat -w

 

# netstat -w 1

input (Total) output

packets errs bytes packets errs bytes colls

20511 0 15672588 20268 0 15707540 0

19291 0 13446422 19244 0 13425454 0

18003 0 12721536 17774 0 12695012 0

17730 0 12885040 17603 0 12908376 0

18651 0 13454564 18445 0 13442760 0

16851 0 12377398 16794 0 12431828 0

 

 

# netstat -w 1 -I em0

input (em0) output

packets errs bytes packets errs bytes colls

9208 0 6154791 9101 0 6146423 0

9446 0 6645904 9411 0 6626134 0

8816 0 6267612 8736 0 6247686 0

8909 0 6560813 8884 0 6591465 0

8777 0 6258408 8694 0 6260341 0

8454 0 5992247 8487 0 6011723 0

 

 

Кроме em0, других активных интерфейсов в системе нет. Т.е. получается, что пакетов реально проходит в 2 раза больше, чем их поступает? Может быть, это из-за работы dummynet?

[networks]

Включил дрова от яндекса. Пока ничего кардинально не изменилось.

 

Вывод top -S после включения новых дров:

 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND

10 root 1 171 52 0K 8K RUN 5:22 42.58% idle

11 root 1 -44 -163 0K 8K WAIT 0:57 24.71% swi1: net

23 root 1 43 0 0K 8K RUN 0:14 5.42% em0_rx_kthread

24 root 1 43 0 0K 8K WAIT 0:14 4.98% em0_rx_kthread

 

 

Мне начинать ковырять правила dummynet, или можно еще что-то сделать (кроме перехода на 7.X)?

[Maxa]

Не надо пока дамминет. Оно на чем-то другом спотыкается. Я свою машинку выше показывала - с тем же дамминетом и теми же em

 

В ядре что есть?

Edited September 16, 2008 by Maxa

[networks]

cpu I686_CPU

ident ROUTER

 

options SCHED_4BSD # 4BSD scheduler

options PREEMPTION # Enable kernel thread preemption

options INET # InterNETworking

options FFS # Berkeley Fast Filesystem

options SOFTUPDATES # Enable FFS soft updates support

options UFS_ACL # Support for access control lists

options UFS_DIRHASH # Improve performance on big directories

options MD_ROOT # MD is a potential root device

options MSDOSFS # MSDOS Filesystem

options CD9660 # ISO 9660 Filesystem

options PROCFS # Process filesystem (requires PSEUDOFS)

options PSEUDOFS # Pseudo-filesystem framework

options GEOM_GPT # GUID Partition Tables.

options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]

options COMPAT_FREEBSD4 # Compatible with FreeBSD4

options COMPAT_FREEBSD5 # Compatible with FreeBSD5

options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI

options KTRACE # ktrace(1) support

options SYSVSHM # SYSV-style shared memory

options SYSVMSG # SYSV-style message queues

options SYSVSEM # SYSV-style semaphores

options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extension

s

options KBD_INSTALL_CDEV # install a CDEV entry in /dev

options AHC_REG_PRETTY_PRINT # Print register bitfields in debug

# output. Adds ~128k to driver.

options AHD_REG_PRETTY_PRINT # Print register bitfields in debug

# output. Adds ~215k to driver.

options ADAPTIVE_GIANT # Giant mutex is adaptive.

 

options IPFIREWALL

options IPFIREWALL_VERBOSE

options IPFIREWALL_VERBOSE_LIMIT=100

options IPDIVERT

options IPFILTER

options IPFILTER_LOG

options IPFILTER_LOOKUP

options IPFILTER_DEFAULT_BLOCK

options TCP_DROP_SYNFIN

options DUMMYNET

options DEVICE_POLLING

options HZ=2000

 

 

Остальное по стандарту. polling на сетевых сейчас отключен (в ядре пока оставил).

[Skylord]

Собрал дрова от яндекса в ядро, вечерком ребутнусь, посмотрю, как будет.

А дрова от Яндекса вообще на другое направлены. Они - для нагруженных серверов, которые сами трафик генерят. Для роутера толку нет....

 

Skylord: если ничего не поможет, будут до 7-ки обновляться. Просто не уверен, что всё остальное не поломается в процессе :)

Нет, я не хочу сказать, что семерка панацея - надо делать все вместе, - но, ИМХО, это один из "кирпичиков" успеха. :-)

Я на рабочем бордере до семерки обновился без проблем... Часть портов, естесственно, придется пересобрать: ту же zebra точно.

Кстати, в чем смысл наличия ipcad'а? Он у меня в свое время несколько процентов процессора таки отъедал... И корректность отдаваемых им данных очень низкая на более-менее серьезной нагрузке. Однозначно надо ставить ng_netflow...

И убери в ipfw все-таки все в таблицы. Чтобы пайпы создавались один раз и скорость резалась сразу для всех одним правилом при помощи указания масок - это ведь великая фишка dummynet'а! Где еще такое есть? ИМХО, надо обязательно этим пользоваться.

 

И попробуй все-таки точно выяснить, где именно засада. Я по себе четко помню: убираю из ipfw направление трафика в пайпы - тут же общий трафик "прыгает" и бьется головой о скорость интерфейса, количество обрабатываемых пакетов очень сильно возрастает, а загрузка CPU наборот - снижается раза в два, а то и больше.... :-)

[networks]

Skylord: видишь ли, тарифная политика обуславливает необходимость индивидуальных скоростей для абонентов. Впрочем, у меня есть мысль, как все-таки можно оптимизировать правила, немного пожертвовав плавностью регулировки скорости, и задействовать таблицы. Над этим надо будет поработать.

 

Завтра попробую сделать так, чтобы пакеты, не нуждающиеся в проходе через pipe-ы, скипали все правила, к ним относящиеся. Возможно, это уменьшит нагрузку, т.к. меньше пакетов будут пробегать через 500 правил ipfw.

[Skylord]

Гм. И насколько индивидуальные эти скорости? Сколько всего вариантов? Все-таки, очевидно, не столько же, сколько абонентов? tablearg в таблицах smallint точно держит - должно хватить. :-) Возможно, конечно, это все не важно и можно не заморачиваться и мне помогло в свое время. Но, повторяюсь, не что-то одно, а все вместе: pcie сетевушки, оптимизация файрволлов (pf+ipfw), переход на семерку...

[IvanI]

а в ipfw зделано чтото типа

ipfw add aaaa skipto 120 all from any to any out xmit $lan_if

ipfw add aaaa skipto 260 all from any to any in recv $lan_if

ipfw add aaaa skipto 670 all from any to any out xmit $wan_if

ipfw add aaaa skipto 870 all from any to any in recv $wan_if

ipfw add aaaa allow all from any to any via lo0

ipfw add aaaa deny all from any to any

или все пакеты проходят по всем правилам 2 раза(ин/оут)?

[networks]

Сегодня сделал, чтобы все пакеты, не относящиеся к интерфейсу, смотрящему на VPN-сервер (т.е. к пайпам), скипали все правила пайпов без прохода по ним. К сожалению, пока это ничего не дало.

[YuryD]

Да не при чем тут polling - чего вы его мучаете... Достаточно убрать dummynet и все просто летать будет и затыки все исчезнут. У меня так и было.

Почему нет желания на семерку обновиться? Уж по любому от ULE хуже не станет...

При ~2000 pipe имею такую картину на 6.3 , 100 пользователей, суммарный траффик Current In: 549.3 kB/s (4.4%)

Current Out: 83.4 kB/s

 

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND

10 root 1 171 52 0K 8K RUN 29.5H 31.88% idle

234 root 1 107 0 22208K 21616K RUN 22.3H 29.30% natd

11 root 1 -44 -163 0K 8K WAIT 30.6H 25.88% swi1: net

39 root 1 -68 0 0K 8K - 26.7H 0.15% dummynet

21 root 1 -68 -187 0K 8K WAIT 52:35 0.05% irq17: mykc0

32 root 1 -68 -187 0K 8K WAIT 42:08 0.05% irq21: fxp0

521 root 4 20 -15 15520K 14292K kserel 286:56 0.00% ipcad

409 root 3 20 0 8620K 5580K kserel 73:45 0.00% mpd4

 

Т.е. dummynet вроде не при делах, а вот natd, это да...

[networks]

11 root 1 -44 -163 0K 8K WAIT 30.6H 25.88% swi1: net

 

Обратите внимание на вот этот процесс. У меня он тоже отжирает порядка 10-30% CPU, в зависимости от PPS. Я пока не понял, что это. Вчера гуглил, прочитал что это некий процесс, генерирующий софтверные прерывания.

 

А nat у меня через ipnat, с ним никаких проблем нет.

Edited September 17, 2008 by networks

[Maxa]

Уберите все же поллинг из ядра, тем более с 2000, оптимизируйте файерволл...