FreeBSD hi loading CPU

l1ght · 21 травня, 2014

День добрый, имеется:
9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER i386
Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).
Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же).
Но vmstat -i в норме.

Вот примерно следующее видно:

last pid: 22409;  load averages:  0.52,  0.50,  0.30                                                                                                                   
128 processes: 3 running, 109 sleeping, 16 waiting
CPU:  0.0% user,  0.0% nice,  5.5% system, 27.2% interrupt, 67.3% idle
Mem: 108M Active, 80M Inact, 129M Wired, 132K Cache, 73M Buf, 1543M Free
Swap: 4096M Total, 4096M Free
 
 
 PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   11 root      155 ki31     0K    16K RUN     0   7:38 88.28% idle{idle: cpu0}
   12 root      -72    -     0K   128K CPU1    1   2:46 50.05% intr{swi1: netisr 1}
   11 root      155 ki31     0K    16K RUN     1   5:21 47.36% idle{idle: cpu1}
   12 root      -72    -     0K   128K WAIT    0   0:24  6.01% intr{swi1: netisr 0}
    0 root      -92    0     0K    96K -       0   0:11  2.54% kernel{em1 taskq}
    0 root      -92    0     0K    96K -       1   0:15  0.63% kernel{em0 taskq}

interrupt                          total       rate
irq16: xhci0 ehci0                   891          1
irq19: atapci0+                     4995          8
irq23: ehci1                         893          1
cpu0:timer                       1216146       2122
irq256: em0                      2221212       3876
irq257: em1                      1758013       3068
irq258: hdac0                         41          0
cpu1:timer                       1187698       2072
Total                            6389889      11151

Ну это моменты когда нагрузка растёт и машина с ней справляется.

А бывают моменты когда машина просто в кору падает и всё. Поэтому данных что происходит тогда привести не могу.

Но то что я на скорую руку смотрел в принципе vmstat -i ничего криминального не показывает.

Какие будут идеи?

Может чего сильно в sysctl перекрутил?

kern.ipc.nmbclusters=60000
kern.ipc.somaxconn=8192
kern.ipc.maxsockets=204800
net.inet.udp.maxdgram=57344
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.randomized=0
net.inet.tcp.nolocaltimewait=1
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.icmp.bmcastecho=0
net.inet.ip.ttl=64
net.inet.tcp.drop_synfin=1
net.inet.tcp.syncookies=1
net.inet.ip.dummynet.expire=1
net.inet.ip.fw.dyn_buckets=2048
net.inet.tcp.maxtcptw=40960
kern.ipc.maxsockbuf=16777216
net.inet.tcp.recvspace=262144
net.inet.ip.intr_queue_maxlen=8192
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.pipe_slot_limit=1000
kern.maxfilesperproc=200000
kern.ipc.shmmax=67108864
net.inet.tcp.rfc3390=0
net.inet.ip.fw.autoinc_step=1
net.inet.tcp.blackhole=2
net.inet.icmp.maskrepl=1
net.inet.udp.blackhole=1
net.link.ether.inet.max_age=30
net.inet.tcp.sendspace=262144
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.sendbuf_inc=524288
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.ip.random_id=1
net.inet.ip.rtexpire=60
net.inet.ip.rtminexpire=2
net.inet.ip.rtmaxcache=1024
net.inet.icmp.drop_redirect=1
net.inet.ip.redirect=0
kern.maxfiles=204800
net.inet.tcp.delayed_ack=0
dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.1.rx_int_delay=200
dev.em.1.tx_int_delay=200
dev.em.2.rx_int_delay=200
dev.em.2.tx_int_delay=200
dev.em.3.rx_int_delay=200
dev.em.3.tx_int_delay=200
net.graph.recvspace=8388608
net.graph.maxdgram=8388608
net.inet.icmp.icmplim=200
net.inet.udp.recvspace=262144
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.interrupt=0
kern.random.sys.harvest.point_to_point=0
net.inet.ip.fw.dyn_buckets=16384
net.inet.ip.fw.dyn_max=65535
kern.ipc.shmall=128000000         
net.inet.tcp.msl=15000   
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.1.rx_abs_int_delay=4000
dev.em.1.tx_abs_int_delay=4000
dev.em.2.rx_abs_int_delay=4000
dev.em.2.tx_abs_int_delay=4000
dev.em.3.rx_abs_int_delay=4000
dev.em.3.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096
dev.em.1.rx_processing_limit=4096
dev.em.2.rx_processing_limit=4096
dev.em.3.rx_processing_limit=4096
net.route.netisr_maxqlen=4096
net.inet.ip.intr_queue_maxlen=10240
net.isr.dispatch=deferred
net.link.bridge.pfil_onlyip=0
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
net.link.bridge.ipfw=0
net.link.bridge.ipfw_arp=0
net.inet.tcp.mssdflt=1460
net.inet.tcp.syncache.rexmtlimit=0
net.inet.tcp.icmp_may_rst=0
vfs.read_max=128
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
vfs.ufs.dirhash_maxmem=16777216
net.raw.recvspace=65534
net.raw.sendspace=65534
net.inet.raw.maxdgram=65534
net.inet.raw.recvspace=65534
kern.ipc.shm_use_phys=1

Да и в sockstat никакого криминала нет... Уже извёлся незнаю чего и думать

Reality · 21 травня, 2014

Что за карта, какие нагрузки?

l1ght · 21 травня, 2014

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

ronin_zp · 21 травня, 2014

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

выкидывате эти, ставьте с чипом не менее 82576.

На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к.

Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике

PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц.

ну и посмотрите что именно проц нагружает

pmcstat -S instructions -O /tmp/sample.out &

sleep 30 && killall pmcstat

pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25

Відредаговано 21 травня, 2014 ronin_zp

l1ght · 22 травня, 2014

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

выкидывате эти, ставьте с чипом не менее 82576.

На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к.

Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике

PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц.

ну и посмотрите что именно проц нагружает

pmcstat -S instructions -O /tmp/sample.out &

sleep 30 && killall pmcstat

pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25

Спасибо за подсказку, буду смотреть. Не знаю, как у вас при 18кппс загибалось, у меня всё шуршит аж бегом

Только вот у моей проблемы нет никакой систематики, по крайней мере не было.

Может профайлинг чего покажет...

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке

ronin_zp · 22 травня, 2014

У меня была фря с 1000 с копейками правил фаервола ( на тот момент ).

После оптимизации фаервола стало несколько полегче, но фиг заставишь клиентов "любимый" провайдерами мюторрент корректно настроить, точнее отключить его фирменный протокол.

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

ronin_zp · 22 травня, 2014

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке

не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?

l1ght · 22 травня, 2014

Вот как.... Чтож тогда всё стало понятно, значит будем думать про замену!

Очень благодарен.

Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет )

Так что жду ещё идей

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке

не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?

Да у меня вообще sip трафик незамечен, и ничего у меня вроде его не использует.

Если не ошибаюсь SIP - для айпи телефонии?

l1ght · 22 травня, 2014

А кхм, если вы про это http://habrahabr.ru/post/168607/ - сначала внешняя сетевая была 82574L, а потом, всё переехало на двух портовую серверную.

И была ровно та же жопа...

ronin_zp · 22 травня, 2014

Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет )

ну перед апгрейдо сделать профилирование ядра при нагрузке не помешает ;-) Скорее всего перед профилированием прийдётся сделать kldload pmc

блин как-то не очень звучит команда

кстати, посмотри в момент нагрузки top -HSCP и если там много нагрузки на echi - отключи в биосе юсб

Відредаговано 22 травня, 2014 ronin_zp

KaYot · 22 травня, 2014

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

maxx · 22 травня, 2014

Начинать надо с фразы
проц кстати двухядерка пень 4
И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

Reality · 22 травня, 2014

Начинать надо с фразы
проц кстати двухядерка пень 4
И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.
присоединяюсь. I5+intel ET решит вашу проблему.

Че
Начинать надо с фразы
проц кстати двухядерка пень 4
И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.
присоединяюсь. I5+intel ET решит вашу проблему.

Чем решит? В кору будет падать чуть попозже? Бред... По теме, дело в картах... поэтому собственно сразу и задал этот вопрос... Хотя, тоже... У нас стоят TP-LINK TG-3468 в количестве 5-ти штук. Та что смотрит в локалку 12-14к держит

Відредаговано 22 травня, 2014 Reality

masters · 22 травня, 2014

Сталкивался пол года назад с такой проблемой, проц 4 ядра ксеон, карта ЕТ. Без явной зависимости загрузка проца росла до 100%, правда сервер не ложился, но тупил страшно.

Тюнинг особо не помог, загрузка просто стала чуть меньше - в районе 50-60%. И всплески реже. Помогла только фильтрация на свичах - кто-то из юзеров вируса словил.

Так что не торопитесь менять железо, быстрей всего это Вам ничем не поможет.

Відредаговано 22 травня, 2014 masters

maxx · 22 травня, 2014

Бред уважаемый это если у вас от 50 кппс сервер в кору падает. По теме, уже давно обоссано и про бсд, и про сетевухи и про сендибридж процы. А количество ппс косвенно позволяет судить о количестве клиентов, что в свою очередь наталкивает на то что люди вполне в состоянии купить нормальную сетевую.

adeep · 22 травня, 2014

Начинать надо с фразы
проц кстати двухядерка пень 4
И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.
присоединяюсь. I5+intel ET решит вашу проблему.

Че
Начинать надо с фразы
проц кстати двухядерка пень 4
И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.
присоединяюсь. I5+intel ET решит вашу проблему.
Чем решит? В кору будет падать чуть попозже? Бред... По теме, дело в картах... поэтому собственно сразу и задал этот вопрос... Хотя, тоже... У нас стоят TP-LINK TG-3468 в количестве 5-ти штук. Та что смотрит в локалку 12-14к держит

12k pps это вообще ни о чем. На em легко выжимается до полугига. Гиг на шустрых ядрах/яндекс драйверах.

у ТС включен net.isr Его выключение чуть разгрузит систему. И позволит точнее понять где проблема.

rx_int_delay и tx_int_delay можно увеличить до 500. Не забывайте про глюк, когда эти параметры реально применяются только на второй раз их применения.

покажите netstat -w 1 -I em0/em1/em2 в пиковые моменты загрузки проца

Ну и проц сменить. P4 двухядерный - ни о чем.

wantmore · 22 травня, 2014

День добрый, имеется:

9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER i386

Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).

Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же).

Возможно спам на порт 6881. Сделайте tcpdump или сразу добавьте в файерволл правило

count ip from any to me dst-port 6881 in limit dst-addr 500

и понаблюдайте.

BARVIT · 22 травня, 2014

Это эпидемия какая-то, теже яйца, только FreeBSD 8.4, процессор Dual Core G2020 2.9GHz/5GT/s/3MB (BX80637G2020) s1155 BOX, сетевая ET двухголовая, нет систематики никакой, но обычно вечером, все один в один как у ТС... хз что делать

Вот в момент нарастания нагрузки, но сервер потом попустило и продолжил работать, но в основном просто захлебывается.

Почему так неизвестно.

Відредаговано 22 травня, 2014 BARVIT

2,2k · 22 травня, 2014

ipfw list покажи

BARVIT · 22 травня, 2014

00005 fwd 127.0.0.1,80 ip from 172.32.0.0/20 to not me dst-port 80

00006 fwd 127.0.0.1,80 ip from table(47) to not me dst-port 80

00007 allow ip from table(2) to 82.117.226.38 via igb1.300

00007 allow ip from 82.117.226.38 to table(2) via igb1.300

00008 allow ip from table(2) to 195.64.136.182 via igb1.300

00008 allow ip from 195.64.136.182 to table(2) via igb1.300

06000 nat 1 ip from table(2) to not table(9) via igb0.1607

06001 nat 1 ip from any to 46.164.129.226 via igb0.1607

11000 allow ip from table(3) to 212.72.143.0/24 via igb1.300 in

11001 allow ip from 212.72.143.0/24 to table(4) via igb1.300 out

12000 pipe tablearg ip from table(3) to any via igb1.300 in

12001 pipe tablearg ip from any to table(4) via igb1.300 out

13000 allow ip from any to 10.100.0.1 via igb1.300

13000 allow ip from 10.100.0.1 to any via igb1.300

13001 allow ip from 46.164.129.226 80 to any via igb1.300

13001 allow ip from any to 46.164.129.226 dst-port 80 via igb1.300

65531 deny ip from table(10) to any via igb1.300

65532 deny ip from any to table(10) via igb1.300

65533 deny ip from table(2) to any via igb1.300

65535 allow ip from any to any

DemonidZe · 22 травня, 2014

Это эпидемия какая-то, теже яйца, только FreeBSD 8.4, процессор Dual Core G2020 2.9GHz/5GT/s/3MB (BX80637G2020) s1155 BOX, сетевая ET двухголовая, нет систематики никакой, но обычно вечером, все один в один как у ТС... хз что делать

Вот в момент нарастания нагрузки, но сервер потом попустило и продолжил работать, но в основном просто захлебывается.

проблемы.JPG

12.JPG

Почему так неизвестно.

присоединяюсь!!! тоже самое происходит при этом не зависит от трафика или кол-ве ппс, может при загрузке +- 30% жевать 100к ппс и 500-600 мегов трафика и при 20-30к ппс с трафиком 200-250 мег упираться в 100% .сетевая ЕТ проц AMD FX-8350

BARVIT · 22 травня, 2014

ух блин уже трое нас )) от трафика вообще никак не зависит, хоть 50 мбит используется.

Відредаговано 22 травня, 2014 BARVIT

sanyadnepr · 22 травня, 2014

ух блин уже трое нас )) от трафика вообще никак не зависит, хоть 50 мбит используется.

При этом полезной инфы для диагностики 0. Где тспдамп ? Завернуть весь внешний траф на соседний порт свича, в момент проблемы, снифить чем угодно и анализировать.

DemonidZe · 22 травня, 2014

ух блин уже трое нас )) от трафика вообще никак не зависит, хоть 50 мбит используется.

При этом полезной инфы для диагностики 0. Где тспдамп ? Завернуть весь внешний траф на соседний порт свича, в момент проблемы, снифить чем угодно и анализировать.

ну мне завернуть не получится сервер находится далековато от меня , максимум только tcpdump как проявится конечно соберу стату.

Відредаговано 22 травня, 2014 DemonidZe

l1ght · 22 травня, 2014

А я думал я один такой дурак )

Меня кстати net.isr спасал в такие моменты. Когда он был выключен - его включение спасло сервер от падения в кору, он конечно был нагружен очень, но нормально себя чувствовал.

Кстати кто ещё подскажет - не хотят грузится параметры из loader.conf после недавнего мажорного обновления с 9.0 до 9.2.

Лично у меня спам на определенный порт отменяется, т.к. 6881 порт у меня ничем не слушается и включен blackhole.

Да и вообще, сокстат никакого криминала не показывает

Я правило с каунтом добавил - но думаю счётчик вообще дергатся не будет.

И почему сразу выкинуть железо? Ну живёт оно себе нормально, не перенагружается

hw.model: Intel® Pentium® CPU G860 @ 3.00GHz

Завернуть траф на соседний порт свича просто не могу, т.к. аплинк зашёл прямо в машину.

Відредаговано 22 травня, 2014 L1ght

Увійти

FreeBSD hi loading CPU

Рекомендованные сообщения

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

nightfly

major12

nightfly

Posted Images

Создайте аккаунт или войдите в него для комментирования

Создать аккаунт

Вхід

Зараз на сторінці 0 користувачів

Схожий контент