ApmeM

что он контролирует я знаю. просто не мог подумать что он будет так валить систему. Каюсь - мать десктопная.

Небольшое дополнение к данной теме.... Год назад я так и не смог запустить софтроутер с 10 гиговыми карточками в стабильную работу. банально отобрали сервер для других нужд. В этом году пришлось вводить второй сервер, и опять наткнулся на проблему приведенную в цитате. И так хронология решения данной проблемы: 1. перепробовал все стабильные ядра на данный момент 2. перепробовал старые ядра. 3. поотключал все что только можно, + тюнинг системы 4 менял сетевые, драйвера на сетевые Никакого результата это не принесло. Система под нагрузкой в 2,5 гига работала стабильно 42 минуты (данный момент не понятен, но присутствует) Было принято решение связаться с korvin2000 и пожаловаться ему на тяжкую судьбу и заодно получить отеческий совет. Совет был получен, произведен дополнительный тюнинг. Теперь система смогла проработать 1 час 40 минут до аварии. Дальнейшие действия по решению не помню, но в интернете, в теме которая совсем не касалась данной проблемы а шло обсуждение проблем с файлом sch_generic.c была рекомендация использовать при загрузке системы опцию pcie_aspm=off В данный момент система работает уже вторую неделю итого при загрузке также выполняем следующие настройки выдержка из скрипта Отдельная благодарность Александру ака korvin2000 за помощь.

EM4626H-XG-XFP случайно не продаете?

тогда в резерв его пожалуйста.

у него управление через telnet имеется?

с учетом отсутствия пыли, интересует количество коммутаторов для продажи.

Сколько коммутаторов готово к продаже ? Уточните состояние и количество рабочих портов.

в данный момент имеем такую картину. На какой параметр обратить самое пристальное внимание? last pid: 59963; load averages: 3.03, 3.03, 2.86 up 1+21:57:59 17:01:07 113 processes: 10 running, 74 sleeping, 29 waiting CPU 0: 0.4% user, 0.0% nice, 3.5% system, 61.8% interrupt, 34.3% idle CPU 1: 1.2% user, 0.0% nice, 3.1% system, 57.9% interrupt, 37.8% idle CPU 2: 1.2% user, 0.0% nice, 3.5% system, 33.1% interrupt, 62.2% idle CPU 3: 2.0% user, 0.0% nice, 6.7% system, 24.8% interrupt, 66.5% idle Mem: 42M Active, 2159M Inact, 1478M Wired, 413M Buf, 216M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K RUN 3 37.4H 74.12% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 2 36.9H 58.20% idle{idle: cpu2} 12 root -92 - 0K 544K WAIT 0 625:46 44.68% intr{irq266: igb2:que} 11 root 155 ki31 0K 64K RUN 1 32.9H 39.16% idle{idle: cpu1} 12 root -92 - 0K 544K RUN 1 618:32 37.65% intr{irq271: igb3:que} 11 root 155 ki31 0K 64K RUN 0 22.4H 36.67% idle{idle: cpu0} 12 root -92 - 0K 544K WAIT 2 214:26 15.67% intr{irq258: igb0:que} 12 root -92 - 0K 544K WAIT 2 214:42 13.38% intr{irq263: igb1:que} 12 root -92 - 0K 544K WAIT 3 209:08 13.28% intr{irq259: igb0:que} 12 root -92 - 0K 544K CPU1 1 209:23 12.35% intr{irq257: igb0:que} 12 root -92 - 0K 544K WAIT 3 214:19 11.67% intr{irq264: igb1:que} 12 root -92 - 0K 544K CPU0 0 217:09 11.52% intr{irq256: igb0:que} 12 root -92 - 0K 544K RUN 1 204:35 11.38% intr{irq262: igb1:que} 12 root -92 - 0K 544K RUN 0 194:15 10.25% intr{irq261: igb1:que} 41785 root 24 0 286M 155M select 3 154:56 7.23% mpd5{mpd5} 0 root -92 0 0K 416K - 3 35:45 2.54% kernel{igb2 que} 0 root -92 0 0K 416K - 3 35:33 2.10% kernel{igb3 que} 2 root -16 - 0K 16K pftm 0 29:42 1.03% pfpurge 42091 root 21 0 22928K 6164K select 2 20:07 0.93% zebra 0 root -92 0 0K 416K - 2 14:05 0.54% kernel{igb0 que} 12 root -60 - 0K 544K WAIT 1 13:59 0.00% intr{swi4: clock} 0 root -92 0 0K 416K - 2 10:28 0.00% kernel{dummynet} 41665 root 20 0 12184K 1644K select 2 3:07 0.00% syslogd 15 root -16 - 0K 16K - 0 2:44 0.00% yarrow 42341 root 20 0 29736K 9900K select 2 1:58 0.00% ospfd 13 root -16 - 0K 64K sleep 3 1:14 0.00% ng_queue{ng_queue1} 13 root -16 - 0K 64K sleep 3 1:12 0.00% ng_queue{ng_queue3} 13 root -16 - 0K 64K sleep 2 1:12 0.00% ng_queue{ng_queue0} 13 root -16 - 0K 64K sleep 3 1:12 0.00% ng_queue{ng_queue2} root@nas-4 /]# vmstat -i interrupt total rate irq1: atkbd0 5 0 irq19: atapci0+ 268242 1 cpu0:timer 682887799 4125 irq256: igb0:que 0 1356654144 8196 irq257: igb0:que 1 733963724 4434 irq258: igb0:que 2 738492205 4461 irq259: igb0:que 3 715963827 4325 irq260: igb0:link 5 0 irq261: igb1:que 0 652965725 3945 irq262: igb1:que 1 720284849 4351 irq263: igb1:que 2 743332012 4491 irq264: igb1:que 3 729005282 4404 irq265: igb1:link 6 0 irq266: igb2:que 0 1080964924 6531 irq267: igb2:que 1 694314 4 irq268: igb2:que 2 2485210 15 irq269: igb2:que 3 752871 4 irq270: igb2:link 5 0 irq271: igb3:que 0 1074474003 6491 irq272: igb3:que 1 2658713 16 irq273: igb3:que 2 682522 4 irq274: igb3:que 3 2608000 15 irq275: igb3:link 6 0 cpu2:timer 682560824 4124 cpu1:timer 682549559 4123 cpu3:timer 680047764 4108 Total 11284296540 68179 41628/8172/49800 mbufs in use (current/cache/total) 33446/5728/39174/131072 mbuf clusters in use (current/cache/total/max) 33446/5210 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 77303K/13499K/90802K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines

День добрый. В данный момент имеются два сервера доступа под управлении freebsd9. [root@nas-1 /]# uname -a FreeBSD nas-1.sunline.com.ua 9.0-RELEASE FreeBSD 9.0-RELEASE #5: Wed Dec 26 04:26:09 EET 2012 root@nas-4:/usr/obj/usr/src/sys/NAS amd64 и [root@nas-4 /]# uname -a FreeBSD nas-4.sunline.com.ua 9.0-RELEASE FreeBSD 9.0-RELEASE #5: Wed Dec 26 04:26:09 EET 2012 root@nas-4:/usr/obj/usr/src/sys/NAS amd64 на обоих серверах установлены сетевые интел, на сетевых два порта связаны через lacp и включены в агрегацию. еще два порта, также связаны в lacp, и включены в корень сети. Две недели оба сервера проработали нормально. после чего, с разницей в сутки, перестали отвечать на внешние разражители (ping, ssh и т.д.) включившись в сервер напрямую увидел, что сервера живу, но пинг на адреса соседних серверов не проходит. зато есть ответ от самого себя. вот интерфейсы одного из серверов [root@nas-4 /]# ifconfig lagg1 lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=400a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO> ether 90:e2:ba:08:90:00 inet 10.100.100.64 netmask 0xffffff00 broadcast 10.100.100.255 media: Ethernet autoselect status: active laggproto lacp laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> [root@nas-4 /]# ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=400a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO> ether 90:e2:ba:08:8f:a0 inet 10.100.110.64 netmask 0xffffff00 broadcast 10.100.110.255 media: Ethernet autoselect status: active laggproto lacp laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> Через несколько дней ожидаю подобного поведения. Собственно вопрос - на что обратить внимание при вознокновении проблемы? Игде можно поискать проблему до падения интерфейсов? в догонку некоторая информация [root@nas-1 /]# cat /boot/loader.conf hw.igb.rxd=2048 hw.igb.txd=2048 hw.igb.max_interrupt_rate=32000 net.graph.maxdata=65536 net.graph.maxalloc=65536 #net.link.ether.inet.log_arp_permanent_modify=0 #net.link.ether.inet.log_arp_movements=0 #net.link.ether.inet.log_arp_wrong_iface=0 #net.link.log_link_state_change=0 #net.link.ether.inet.max_age=60 kern.maxfiles=50000 net.inet.tcp.tcbhashsize=4096 ## DADV TUNING # for other protocols (IP & PPPoE?) net.isr.defaultqlimit=4096 # default outgoing interface queue length # used by lagg etc. net.link.ifqmaxlen=10240 root@nas-1 /]# cat /etc/sysctl.conf | grep -v '#' kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=131072 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.intr_queue_drops=0 net.inet.ip.redirect=0 net.inet.ip.fw.one_pass=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.bmcastecho=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 kern.ipc.nmbclusters=131072 net.link.ether.inet.log_arp_permanent_modify=0 net.link.ether.inet.log_arp_movements=0 net.link.ether.inet.log_arp_wrong_iface=0 net.link.log_link_state_change=0 net.inet.ip.dummynet.hash_size=512 dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 dev.igb.2.rx_processing_limit=4096 dev.igb.3.rx_processing_limit=4096 [root@nas-1 /]# /etc/sysctl.conf и /boot/loader.conf одинаковы на обоих серверах.

есть вопрос, а сколько у вас кушает mpd. у себя вижу загрузку по CPU порядка 20-40%.

аналогичная картина наблюдается и на freebsd9 + mpd5.6

сейчас поднимаю на тестовой машине 9-ку. на 8-ке пытался работать, но ее работа с igb картами оставляла желать лучшего. а вот за http://dadv.livejour...com/138951.html - спасибо. как-то упустил я эту статью. попробую поиграться с # netgraph queue sizes tuning, see vmstat -z|egrep 'ITEM|NetGraph' net.graph.maxdata=65536 net.graph.maxalloc=65536 так как на данный момент имею net.graph.maxdata: 512 net.graph.maxalloc: 64000

День добрый. Прошу помощи в поиске и устранении причин перезагрузки NAS-сервера. Исходный данные таковы проц Intel® Core™ i5-3570 CPU @ 3.40GHz RAM 4G мать Z68A-D3H-B3 сетевые 4х портовая интел Схема включения такова - igb1 смотрит в dgs3610-26G. на этом интерфейсе подняты vlan в количестве 600. igb0 смотрит в корень сети. История болезни Сервер работал как NAS для pppoe соединений(mpd5). количество сессий, которое принимал сервер составляло 1000. присутствует NAT. В час пик нагрузка на сетевом интерфейсе порядка 800-900 мегабит. пекетов 80Кpps. CPU ifle time 75% в час пик. Так как мощностей хватает на большую нагрузук, то было принято решение использовать lacp было пересобранно ядро с переметром device lagg настройки интерфесов где x.x.x.x y.y.y.y белые адреса, я их использую для нат-а теперь в час пик имеем следующую картину количество pppoe сесий 1600-1700 трафик 1,2 -1,4G на прием и 0,6-0,8G на отдачу. cpu idle time 40-50% . Проблема в том, что сервер временами, без обьявления войны, уходит в ребут. никаких записей в логах нет. vmcore тоже нет. Перезагружается он не только в час пик, но и при минимальной нагрузке. Подскажите, в какую сторону копать? из параметров cat /boot/loader.conf | grep -v "#" net.graph.maxalloc=64000 net.link.ether.inet.log_arp_permanent_modify=0 net.link.ether.inet.log_arp_movements=0 net.link.ether.inet.log_arp_wrong_iface=0 net.link.log_link_state_change=0 net.link.ether.inet.max_age=60 kern.maxfiles=50000 if_lagg_load="YES" cat /etc/sysctl.conf | grep -v "#" kern.ipc.somaxconn=1024 kern.ipc.maxsockbuf=8388608 kern.ipc.maxsockets=131072 net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.intr_queue_drops=0 net.inet.ip.redirect=0 net.inet.ip.fw.one_pass=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.bmcastecho=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 net.graph.maxdgram=768000 net.graph.recvspace=768000 net.inet6.ip6.redirect=0 kern.polling.enable=0 kern.polling.user_frac=0 net.link.ether.inet.log_arp_permanent_modify=0 net.link.ether.inet.log_arp_movements=0 net.link.ether.inet.log_arp_wrong_iface=0 net.link.log_link_state_change=0 net.inet.ip.dummynet.hash_size=512 kern.ipc.nmbclusters=65536 vmstat -i interrupt total rate irq18: ehci0 7 0 irq19: atapci0+ 178161 2 irq23: ehci1 9 0 cpu0: timer 267580230 4000 irq256: igb0 492123476 7356 irq257: igb0 205995552 3079 irq258: igb0 215108537 3215 irq259: igb0 205141038 3066 irq260: igb0 5 0 irq261: igb1 509699078 7619 irq262: igb1 215899619 3227 irq263: igb1 212905420 3182 irq264: igb1 215361483 3219 irq265: igb1 6 0 irq266: igb2 509892819 7622 irq267: igb2 205148 3 irq268: igb2 204286 3 irq269: igb2 380026 5 irq270: igb2 5 0 irq271: igb3 477285468 7135 irq272: igb3 187914 2 irq273: igb3 200212 2 irq274: igb3 198526 2 irq275: igb3 6 0 cpu1: timer 267580049 4000 cpu3: timer 267580049 4000 cpu2: timer 267580049 4000 Total 4331287178 64750 netstat -m 17050/7145/24195 mbufs in use (current/cache/total) 17038/4680/21718/204800 mbuf clusters in use (current/cache/total/max) 613/667 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 38340K/11146K/49486K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines pfctl -sn No ALTQ support in kernel ALTQ related functions disabled nat pass on lagg1 inet from 10.10.0.0/16 to ! <trust_networks> -> y.y.y.y/27 source-hash 0x6b6b5d8666236378ab72de2d391bff62

мать Dec 3 14:20:50 gw_neo kernel: [31352.219339] Hardware name: Z68A-D3H-B3

так и не смог заставить работать 10G на i5. Собственно что было сделано - откатил ядро на версию < 3.3. Т.е. с 3,6,6 перешел на 3,0,53. дополнительно выполнил команды ethtool -K ethX tso off tx on sg on gro off lro off ifconfig ethX txqueuelen 10000 драйвера сетевых откатил на "проверенную" версию, т.е. на другой машине аналогичная карточка с такими драйверами работает отлично. Попытался нагрузить сервер iperf-ом. получил показания прием/отдача 5/3 G одновременно. Или 8G в одну сторону. Можно было бы получить и больше, но не хватило мощностей для создания нагрузки. И что получил в итоге - теперь сервер не подвисает наглухо, теперь он просто перегружается. На момент ребута загрузка интерфейса составляла 3,5/1,5G. LA~0.1 CPU SI 35-40% на каждом ядре. CPU idle time 65% в ЧНН. и рушилось все это дело с такими ошибками Dec 3 14:20:40 gw_neo kernel: [31341.684411] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:40 gw_neo kernel: [31341.883829] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:42 gw_neo kernel: [31343.682696] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:42 gw_neo kernel: [31343.882122] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:44 gw_neo kernel: [31345.680983] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:44 gw_neo kernel: [31345.880408] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:46 gw_neo kernel: [31347.679258] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:46 gw_neo kernel: [31347.878714] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:48 gw_neo kernel: [31349.677562] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:48 gw_neo kernel: [31349.876988] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:48 gw_neo bird: KRT: Received route 10.250.250.0/24 with strange next-hop 10.250.250.1 Dec 3 14:20:50 gw_neo kernel: [31351.675838] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:50 gw_neo kernel: [31351.875269] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:50 gw_neo kernel: [31351.675838] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:50 gw_neo kernel: [31351.875269] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:50 gw_neo kernel: [31352.219332] ------------[ cut here ]------------ Dec 3 14:20:50 gw_neo kernel: [31352.219338] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x14b() Dec 3 14:20:50 gw_neo kernel: [31352.219339] Hardware name: Z68A-D3H-B3 Dec 3 14:20:50 gw_neo kernel: [31352.219340] NETDEV WATCHDOG: eth2 (ixgbe): transmit queue 0 timed out Dec 3 14:20:50 gw_neo kernel: [31352.219341] Modules linked in: tun xt_set ip_set_hash_ip ip_set 8021q igb ixgbe dca Dec 3 14:20:50 gw_neo kernel: [31352.219346] Pid: 0, comm: swapper Tainted: G W 3.0.53-gentoo #1 Dec 3 14:20:50 gw_neo kernel: [31352.219347] Call Trace: Dec 3 14:20:50 gw_neo kernel: [31352.219348] <IRQ> [<ffffffff8103aa51>] warn_slowpath_common+0x80/0x98 Dec 3 14:20:50 gw_neo kernel: [31352.219354] [<ffffffff8103aafd>] warn_slowpath_fmt+0x41/0x43 Dec 3 14:20:50 gw_neo kernel: [31352.219356] [<ffffffff81443e82>] ? netif_tx_lock+0x45/0x76 Dec 3 14:20:50 gw_neo kernel: [31352.219358] [<ffffffff81443fec>] dev_watchdog+0xeb/0x14b Dec 3 14:20:50 gw_neo kernel: [31352.219360] [<ffffffff81046ef2>] run_timer_softirq+0x1c4/0x28d Dec 3 14:20:50 gw_neo kernel: [31352.219362] [<ffffffff81443f01>] ? netif_tx_unlock+0x4e/0x4e Dec 3 14:20:50 gw_neo kernel: [31352.219365] [<ffffffff81017cce>] ? lapic_next_event+0x10/0x14 Dec 3 14:20:50 gw_neo kernel: [31352.219367] [<ffffffff81040242>] __do_softirq+0xbe/0x17b Dec 3 14:20:50 gw_neo kernel: [31352.219370] [<ffffffff81061a02>] ? tick_program_event+0x1a/0x1c Dec 3 14:20:50 gw_neo kernel: [31352.219374] [<ffffffff8152ed0c>] call_softirq+0x1c/0x30 Dec 3 14:20:50 gw_neo kernel: [31352.219377] [<ffffffff81003ae6>] do_softirq+0x33/0x69 Dec 3 14:20:50 gw_neo kernel: [31352.219379] [<ffffffff810404a7>] irq_exit+0x3f/0x9c Dec 3 14:20:50 gw_neo kernel: [31352.219381] [<ffffffff8101815b>] smp_apic_timer_interrupt+0x77/0x85 Dec 3 14:20:50 gw_neo kernel: [31352.219383] [<ffffffff8152e4d3>] apic_timer_interrupt+0x13/0x20 Dec 3 14:20:50 gw_neo kernel: [31352.219384] <EOI> [<ffffffff812b5793>] ? acpi_idle_enter_bm+0x200/0x234 Dec 3 14:20:50 gw_neo kernel: [31352.219388] [<ffffffff812b578e>] ? acpi_idle_enter_bm+0x1fb/0x234 Dec 3 14:20:50 gw_neo kernel: [31352.219390] [<ffffffff814153e6>] cpuidle_idle_call+0xd9/0x157 Dec 3 14:20:50 gw_neo kernel: [31352.219393] [<ffffffff8100123c>] cpu_idle+0x56/0x78 Dec 3 14:20:50 gw_neo kernel: [31352.219395] [<ffffffff8150ab49>] rest_init+0x6d/0x6f Dec 3 14:20:50 gw_neo kernel: [31352.219397] [<ffffffff81a9cad4>] start_kernel+0x343/0x34e Dec 3 14:20:50 gw_neo kernel: [31352.219399] [<ffffffff81a9c2a6>] x86_64_start_reservations+0xb6/0xba Dec 3 14:20:50 gw_neo kernel: [31352.219401] [<ffffffff81a9c39c>] x86_64_start_kernel+0xf2/0xf9 Dec 3 14:20:50 gw_neo kernel: [31352.219402] ---[ end trace 8720a024bf0aa566 ]--- Dec 3 14:20:50 gw_neo kernel: [31352.219407] ixgbe 0000:01:00.0: eth2: Fake Tx hang detected with timeout of 5 seconds Dec 3 14:20:52 gw_neo kernel: [31353.674115] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:52 gw_neo kernel: [31353.873555] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Dec 3 14:20:54 gw_neo kernel: [31355.672422] ixgbe 0000:01:00.0: eth2: -1 Spoofed packets detected Dec 3 14:20:54 gw_neo kernel: [31355.871891] ixgbe 0000:01:00.1: eth3: -1 Spoofed packets detected Куда еще копать - не знаю. Осталось только проверить гипертрейнинг.... Дальше фантазия заканчивается

Даже для постгреса нужно делать сегментацию.

продолжил експеримент. выставил рекомендованные размеры буферов, отключил flow control по рекомендации. все равно под нагрузкой перестает работать сетевая. в логах появляется ошибка Nov 27 21:29:41 gw_neo kernel: [56984.810590] ------------[ cut here ]------------ Nov 27 21:29:41 gw_neo kernel: [56984.810596] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xf4/0x154() Nov 27 21:29:41 gw_neo kernel: [56984.810597] Hardware name: Z68A-D3H-B3 Nov 27 21:29:41 gw_neo kernel: [56984.810598] NETDEV WATCHDOG: eth2 (ixgbe): transmit queue 0 timed out Nov 27 21:29:41 gw_neo kernel: [56984.810598] Modules linked in: tun xt_set ip_set_hash_ip ip_set 8021q igb(O) ixgbe(O) dca Nov 27 21:29:41 gw_neo kernel: [56984.810604] Pid: 0, comm: swapper/0 Tainted: G O 3.6.6-gentoo #1 Nov 27 21:29:41 gw_neo kernel: [56984.810604] Call Trace: Nov 27 21:29:41 gw_neo kernel: [56984.810605] <IRQ> [<ffffffff8148b10c>] ? dev_watchdog+0xf4/0x154 Nov 27 21:29:41 gw_neo kernel: [56984.810610] [<ffffffff810302a7>] warn_slowpath_common+0x80/0x98 Nov 27 21:29:41 gw_neo kernel: [56984.810612] [<ffffffff81030353>] warn_slowpath_fmt+0x41/0x43 Nov 27 21:29:41 gw_neo kernel: [56984.810614] [<ffffffff8148af91>] ? netif_tx_lock+0x45/0x7a Nov 27 21:29:41 gw_neo kernel: [56984.810616] [<ffffffff8148b10c>] dev_watchdog+0xf4/0x154 Nov 27 21:29:41 gw_neo kernel: [56984.810619] [<ffffffff8103d31e>] run_timer_softirq+0x1d1/0x29b Nov 27 21:29:41 gw_neo kernel: [56984.810621] [<ffffffff8148b018>] ? netif_tx_unlock+0x52/0x52 Nov 27 21:29:41 gw_neo kernel: [56984.810623] [<ffffffff8101d2c9>] ? apic_write+0x11/0x13 Nov 27 21:29:41 gw_neo kernel: [56984.810625] [<ffffffff810371b7>] __do_softirq+0xd4/0x1ad Nov 27 21:29:41 gw_neo kernel: [56984.810628] [<ffffffff8106dbff>] ? tick_program_event+0x1f/0x21 Nov 27 21:29:41 gw_neo kernel: [56984.810630] [<ffffffff81577cec>] call_softirq+0x1c/0x30 Nov 27 21:29:41 gw_neo kernel: [56984.810631] [<ffffffff81003ce8>] do_softirq+0x33/0x6b Nov 27 21:29:41 gw_neo kernel: [56984.810633] [<ffffffff8103743f>] irq_exit+0x3f/0x9a Nov 27 21:29:41 gw_neo kernel: [56984.810635] [<ffffffff8101d856>] smp_apic_timer_interrupt+0x77/0x85 Nov 27 21:29:41 gw_neo kernel: [56984.810637] [<ffffffff81577607>] apic_timer_interrupt+0x67/0x70 Nov 27 21:29:41 gw_neo kernel: [56984.810638] <EOI> [<ffffffff812d3fec>] ? acpi_idle_enter_simple+0xbf/0xf5 Nov 27 21:29:41 gw_neo kernel: [56984.810643] [<ffffffff812d3fe7>] ? acpi_idle_enter_simple+0xba/0xf5 Nov 27 21:29:41 gw_neo kernel: [56984.810645] [<ffffffff8144a15a>] cpuidle_enter+0x12/0x14 Nov 27 21:29:41 gw_neo kernel: [56984.810647] [<ffffffff8144a5f0>] cpuidle_enter_state+0x12/0x3a Nov 27 21:29:41 gw_neo kernel: [56984.810648] [<ffffffff8144a6f0>] cpuidle_idle_call+0xd8/0x14b Nov 27 21:29:41 gw_neo kernel: [56984.810650] [<ffffffff810096f7>] cpu_idle+0x56/0x7f Nov 27 21:29:41 gw_neo kernel: [56984.810652] [<ffffffff81552629>] rest_init+0x6d/0x6f Nov 27 21:29:41 gw_neo kernel: [56984.810655] [<ffffffff81ab2ae5>] start_kernel+0x33b/0x348 Nov 27 21:29:41 gw_neo kernel: [56984.810656] [<ffffffff81ab251d>] ? repair_env_string+0x56/0x56 Nov 27 21:29:41 gw_neo kernel: [56984.810658] [<ffffffff81ab22b2>] x86_64_start_reservations+0xb6/0xbb Nov 27 21:29:41 gw_neo kernel: [56984.810659] [<ffffffff81ab23a9>] x86_64_start_kernel+0xf2/0xf9 Nov 27 21:29:41 gw_neo kernel: [56984.810660] ---[ end trace 9b4294d240768f82 ]--- Nov 27 21:29:41 gw_neo kernel: [56984.810665] ixgbe 0000:01:00.0: eth2: Fake Tx hang detected with timeout of 5 seconds Nov 27 21:29:41 gw_neo bird: KRT: Received route 10.250.250.0/24 with strange next-hop 10.250.250.1 Nov 27 21:29:51 gw_neo kernel: [56994.798027] ixgbe 0000:01:00.0: eth2: Fake Tx hang detected with timeout of 10 seconds Может кто знает, что еще можно подправить?

Исторически так сложилось, что используем Zabbix. Система всем хороша, но без тюнинга базы проживет не долго. После настройки mysql на работу с партициями жить становится легче.

размер буфера 1024 остальные параметры буду пробовать завтра при реальной работе. так как падение происходит при нагрузке более 3-3,5 гиг, то время на установку параметров будет.

gw root # dmesg | grep detected [ 774.569272] ixgbe 0000:01:00.1: eth3: detected SFP+: 6 gw root # ethtool -i eth3 driver: ixgbe version: 3.11.33 firmware-version: 0x1bab0001 bus-info: 0000:01:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes gw root # ethtool -i eth2 driver: ixgbe version: 3.11.33 firmware-version: 0x1bab0001 bus-info: 0000:01:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes gw_neo skripnik # линия в порядке. на соседнем сервере работает без нареканий. есть мысль отключить Flow control, по рекомендации от Интела. /usr/sbin/ethtool -A eth2 autoneg off rx off tx off /usr/sbin/ethtool -A eth3 autoneg off rx off tx off но результат под нагрузкой смогу увидеть только завтра вечером. в прошлый раз с такой ошибкой (Fake Tx hang ...) система положила интерфейс.

таких ошибок у себя не видел? xgbe 0000:01:00.0: eth2: Fake Tx hang detected with timeout of 5 seconds

korvin2000, в можно увидеть вывод ethtool -a eth ethtool -k eth для 10G интерфейса?

Да я бы с радостью пересел бы на железячное решение, но у меня все упирается в порты 10G. мне их нужно как минимум 2 штуки. с учетом этого цена получается заоблочной, как для нас.

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

это обязательно будет сделано. уже идет подготовка к переходу. Нат-ом будет заниматься каждый из pppoe-серверов. у них мощности должно хватить. Но на данном этапе я упираюсь в CPU SI. вот по этому и планирую заменить проц на более производительный.