BETEPAH Опубликовано 6 февраля, 2013 (изменено) · Жалоба Пытаюсь ввести в строй новый сервер такого состава: Материнка: MBD-X9DRH-IF-O Supermicro - 1шт. Проц: Intel Xeon E5-2680W - 2 шт. Сетевые: Intel x540-T1 - 2 шт. Centos 6.3 x64, роутер, шейпинг и доступ клиентов в инет через iptables. С дровами которые шли из коробки 3.6.7 отработал час, потом кернел паник. Скачал с интела последние дрова под сетевухи 3.12. Отработал часов 5 и опять кернел паник. Потом только увидел, что в реадми написано, что надо отключить LRO и GRO. Отключил. Опять отработал около 5 часов и опять кернел паник. Сфоткал на всякий случай, что при этом написано. Я в этом ничего не понимаю. Помогите, меня клиенты съедят. Может и не в сетевухах дело. Пробовал нагружать в пару потоков iperf. Больше суток отработал нормально. Всё-таки не та нагрузка, которую создают пара тысяч человек. Мемтестом сутки гонял - тоже ничего не выявил. Даже не знаю что делать. :( Изменено 6 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 6 февраля, 2013 (изменено) · Жалоба Менять ядро. Собирать самому и искать стабильное по данное железо. Такое бывает не только с шейпингом, а и просто при форвардинге трафика. Стабильными себя показали в этом вопросы 3.2.х, 3.7.х. И что характерно в тестах ничего уронить тоже не удавалось и высер ядра в консоль выглядел практически как в Вашем случае. Изменено 6 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 6 февраля, 2013 · Жалоба возможен косяк с криво прописанным APIC на супермикре, который от сетевухи не зависит в принципе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 7 февраля, 2013 · Жалоба replicant Спасибо за наводку. Никогда бы не подумал, у меня на старом роутере ядро 2.6.18 работало и никаких проблем. Поставил 3.7.6, аптайм уже 11 часов, вроде не падает. Посмотрим дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 февраля, 2013 · Жалоба возможен косяк с криво прописанным APIC на супермикре, который от сетевухи не зависит в принципе. Мимо денег. К тому же сетевухи отдельные вроде как. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 8 февраля, 2013 (изменено) · Жалоба replicant Спасибо за наводку. Никогда бы не подумал, у меня на старом роутере ядро 2.6.18 работало и никаких проблем. Аналогично и мы работали на 2.6.32.х, но заметил одну особенность. Они стабильны были на старом железе. Т.е. если какой-то Intel Core Quad Q9400 и мамка под него на socket 775 и старым чипсетом, то проблем никаких. Как только ушли на E3-E5 Xeon и новые чипы С202-602, то началось массовое помешательство, хотя справедливости ради замечу, что у меня периодичность вывалов была где-то 10-20 дней, но все равно неприятно. Причем сервера типа web/mysql и др. на 2.6.32.х, где нет огромных потоков трафика от сотен и тысяч разных IP адресов, стабильны уже не один год, хотя железо там тоже обновлялось. Изменено 8 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 11 февраля, 2013 (изменено) · Жалоба Рано обрадовался. Аптайм 4 дня, кернел паник нету. Но непонятно почему прерывания загружают два 8-ядерника в полку, даже счас утром, когда нагрузка никакая. На старом роутере один 4-ядерник только ночью загружен в 100%, конфигурация шейперов и iptables абсолютно одинаковая. Куда дальше копать? Ядро попробовал 3.0.62 поставить. То же самое, 5 минут нормальной работы и загрузка процов процентов 5-10. Потом резко ksoftirqd все 16 ядер кладёт в полку. Изменено 11 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 11 февраля, 2013 · Жалоба oprofile Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 11 февраля, 2013 · Жалоба а что там крутится ? нат, фаервол, шейпер ?... хоть чтото опиши Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micol Опубликовано 11 февраля, 2013 · Жалоба Acpi вырубить в ядре пересборкой, intelовские приблуды типа турбо и прочих регуляторов частоты и экономии энергии выключать в биосе Но это все тюнинг, у меня было нечто подобное. Если память не изменяет проблема была в кривой поддержке mq qdisc в tc Остался на 2.6.39 кастомно-собранном. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 (изменено) · Жалоба martini я в самом начале описал, tc + iptables, без ната, просто форвардинг CPU: Intel Sandy Bridge microarchitecture, speed 2700.23 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 1982293 99.8246 no-vmlinux 1143 0.0576 libc-2.12.so 724 0.0365 libdns.so.81.4.1 379 0.0191 oprofiled 331 0.0167 ld-2.12.so 287 0.0145 libisc.so.83.0.3 260 0.0131 bash 111 0.0056 named CPU_CLK_UNHALT...| samples| %| ------------------ 106 95.4955 named 5 4.5045 [vdso] (tgid:1822 range:0x7fff531b7000-0x7fff531b8000) 108 0.0054 libpthread-2.12.so 42 0.0021 grep 36 0.0018 tc 14 7.1e-04 gawk 6 3.0e-04 sshd 4 2.0e-04 libc-2.12.so 4 2.0e-04 sudo 4 2.0e-04 ntpd 3 1.5e-04 ld-2.12.so 3 1.5e-04 libdl-2.12.so 3 1.5e-04 libcrypto.so.1.0.0 2 1.0e-04 libipset.so.2.0.0 1 5.0e-05 ls 1 5.0e-05 sleep 1 5.0e-05 libpthread-2.12.so 1 5.0e-05 libaudit.so.1.0.0 1 5.0e-05 libpam.so.0.82.2 1 5.0e-05 libpcre.so.0.0.1 1 5.0e-05 libplc4.so 1 5.0e-05 libresolv-2.12.so 1 5.0e-05 libselinux.so.1 1 5.0e-05 pam_env.so 1 5.0e-05 utm5_rfw CPU_CLK_UNHALT...| samples| %| ------------------ 1 100.000 [vdso] (tgid:2230 range:0xf77c3000-0xf77c4000) 1 5.0e-05 rsyslogd 1 5.0e-05 ophelp 1 5.0e-05 tr 1 5.0e-05 libgmp.so.3.5.0 1 5.0e-05 libnetsnmpagent.so.20.0.0 1 5.0e-05 libnss3.so 1 5.0e-05 dhcrelay 1 5.0e-05 ipset Изменено 12 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 · Жалоба удалось кое как установить perf, вот что он показал: и что с этим _raw_spin_lock делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 12 февраля, 2013 · Жалоба Что-то между процессорами неладно. Это как бы отсылает нас в RCU. У меня было что-то похожее, но сервак не вис, а просто сыпал багами. Помогла замена ядра на 3.7.5 и 3.7.6, а уже вышло 3.7.7. А прерывания сетевых точно развешены на ядра корректно? cat /proc/interrupts что показывает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 (изменено) · Жалоба Для прерываний брал скрипт отсюда: http://forum.nag.ru/forum/index.php?showtopic=81814&view=findpost&p=798171, распределились прерывания как в этом же посте в примере. Самое интересное, что счас в качестве эксперимента, снял один камень, память соотвественно на 1 проц переставил, сетевухи тоже обе повесил на канал pci-e от этого проца, картина совершенно не изменилась, этот _raw_spin_lock опять в топе. Изменено 12 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 (изменено) · Жалоба В четверг, когда только обновился на 3.7.6 и аптайм был почти 4 часа картина была такая: top - 14:12:52 up 3:53, 2 users, load average: 0.05, 0.12, 0.08 Tasks: 177 total, 1 running, 176 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 95.1%id, 0.0%wa, 0.0%hi, 4.9%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 4.3%si, 0.0%st Cpu2 : 0.5%us, 0.0%sy, 0.0%ni, 92.7%id, 0.0%wa, 0.0%hi, 6.8%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 5.3%si, 0.0%st Cpu4 : 0.4%us, 0.0%sy, 0.0%ni, 93.4%id, 0.0%wa, 0.0%hi, 6.1%si, 0.0%st Cpu5 : 0.4%us, 0.0%sy, 0.0%ni, 94.1%id, 0.0%wa, 0.0%hi, 5.5%si, 0.0%st Cpu6 : 0.4%us, 0.0%sy, 0.0%ni, 95.4%id, 0.0%wa, 0.0%hi, 4.1%si, 0.0%st Cpu7 : 0.4%us, 0.0%sy, 0.0%ni, 95.1%id, 0.0%wa, 0.0%hi, 4.5%si, 0.0%st Cpu8 : 0.0%us, 3.3%sy, 0.0%ni, 90.1%id, 0.0%wa, 0.0%hi, 6.6%si, 0.0%st Cpu9 : 0.4%us, 0.0%sy, 0.0%ni, 94.5%id, 0.0%wa, 0.0%hi, 5.1%si, 0.0%st Cpu10 : 0.5%us, 0.0%sy, 0.0%ni, 93.6%id, 0.0%wa, 0.0%hi, 5.9%si, 0.0%st Cpu11 : 0.4%us, 0.0%sy, 0.0%ni, 93.8%id, 0.0%wa, 0.0%hi, 5.7%si, 0.0%st Cpu12 : 0.4%us, 0.0%sy, 0.0%ni, 94.2%id, 0.0%wa, 0.0%hi, 5.3%si, 0.0%st Cpu13 : 0.0%us, 0.0%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 5.2%si, 0.0%st Cpu14 : 0.0%us, 0.9%sy, 0.0%ni, 91.7%id, 0.0%wa, 0.0%hi, 7.4%si, 0.0%st Cpu15 : 0.0%us, 0.0%sy, 0.0%ni, 95.1%id, 0.0%wa, 0.0%hi, 4.9%si, 0.0%st Mem: 16505204k total, 677956k used, 15827248k free, 17856k buffers Swap: 8388604k total, 0k used, 8388604k free, 183484k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29875 root 20 0 15072 1384 996 S 4.3 0.0 6:46.56 top 1857 named 20 0 1257m 42m 2724 S 4.0 0.3 1:40.04 named 48 root 20 0 0 0 0 S 1.0 0.0 0:45.85 ksoftirqd/8 23 root 20 0 0 0 0 S 0.3 0.0 0:27.77 ksoftirqd/3 28 root 20 0 0 0 0 S 0.3 0.0 0:19.50 ksoftirqd/4 49 root RT 0 0 0 0 S 0.3 0.0 0:15.59 migration/8 68 root 20 0 0 0 0 S 0.3 0.0 0:17.77 ksoftirqd/12 73 root 20 0 0 0 0 S 0.3 0.0 0:16.40 ksoftirqd/13 98 root 20 0 0 0 0 S 0.3 0.0 0:02.90 kworker/1:1 1 root 20 0 19276 1528 1256 S 0.0 0.0 0:01.64 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:12.16 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 7 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/u:0H 14:13:22 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 14:13:23 eth0 75407,79 102315,58 27497,33 118698,11 0,00 0,00 0,00 14:13:23 eth1 102989,61 75506,49 119686,62 27473,74 0,00 0,00 0,00 14:13:23 lo 0,00 0,00 0,00 0,00 0,00 0,00 0,00 Этот сервер просто постоял в работе и начал через пару суток тупить. А теперь такая хрень, сразу после загрузки. :( Изменено 12 февраля, 2013 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 12 февраля, 2013 (изменено) · Жалоба Как совет. Вдруг поможет. Отключите HT (hyper threading) в BIOS. Понятно что кол-во ядер уменьшится вдвое, но с чего-то надо начинать искать. Второй процессор при этом верните физически на место. У себя на двухпроцессорных конфигурациях (правда процы под s1366) отключаю HT. Изменено 12 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 · Жалоба первым делом отключил, прежде чем даже линух установил Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 12 февраля, 2013 (изменено) · Жалоба Contrack отключен(выгрузкой модуля или просто -j NOTRACK)? Кучи линейных правил в iptables нет? Для tc конфигурация нормальная, с хешами? IMHO ksoftirqd выжирающий ресурсы - всегда явное указание на проблемы с софтом, начиная с какого-то pps пакет просто не успевает обрабатываться фаерволом и шейпером до момента приема следующего, сетевая система переходит в режим поллинга и идет лавинообразный рост загрузки. Именно из-за этого у вас и не поменялась картина после замены 4ех ядерного CPU на 8/16, система захлебывается точно так же, но на(к примеру) 20% большем трафике. Изменено 12 февраля, 2013 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 · Жалоба kayot я не понимаю одного, почему сервер отработал какое-то количество времени не тормозя, пару постами выше я показал загрузку после 4 часов работы, а потом начал тупить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 12 февраля, 2013 · Жалоба BETEPAH Ну если contrack не выкошен - возможно таблица выросла до сотен тысяч и внесла свой вклад. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 12 февраля, 2013 (изменено) · Жалоба BETEPAH Ну если contrack не выкошен - возможно таблица выросла до сотен тысяч и внесла свой вклад. Conntrack-то тут причем. Он при простом роутинге вообще не при делах, даже если несколько тысяч там будет в count. NAT на сервере отсутствует. Конечно проверить sysctl -a | grep conntrack_count, но как-то навряд ли это оно. Между прочим -j NOTRACK на маршрутизирующих девайсах как бы не стоит делать на все подряд. Для какого-нибудь web-сервера оно самое то, если какой-то умник там ipv4 forwarding включил, но не для форвардинга трафика. ------------------ Допустим у меня есть машина, которая стоит без NAT и даже без tc и просто форвардит сети через себя с интерфейса на интерфейс в обе стороны. Есс-но включен ipv4 forwarding. В iptables в цепочке FORWARD действие по умолчанию ACCEPT. Т.е. в iptables может вообще не быть никаких правил, чтобы такая конфигурация работала. Для очистки совести можете ввести iptables -I FORWARD -m state --state INVALID -j DROP, чтобы инвалиды дропались на форварде. Зачем тут -j NOTRACK и в какое место его вставлять? Изменено 12 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 12 февраля, 2013 · Жалоба conntrack_count максимум я видел около 300 тысяч, conntrack_max установлен в 1.5 миллионов записей я тоже думаю, что это непричём, такое ощущение, что где-то на уровне железа глюки если есть сомнения в iptables, то вчера ipset прикрутил и теперь выглядит вот-так # Generated by iptables-save v1.4.7 on Tue Feb 12 15:05:28 2013 *mangle :PREROUTING ACCEPT [94551138:130281272469] :INPUT ACCEPT [411:46229] :FORWARD ACCEPT [94550727:130281226240] :OUTPUT ACCEPT [399:32616] :POSTROUTING ACCEPT [94551126:130281258856] COMMIT # Completed on Tue Feb 12 15:05:28 2013 # Generated by iptables-save v1.4.7 on Tue Feb 12 15:05:28 2013 *filter :INPUT ACCEPT [410:46177] :FORWARD DROP [0:0] :OUTPUT ACCEPT [291:26136] :bad_tcp_packets - [0:0] :icmp_packets - [0:0] -A INPUT -p tcp -j bad_tcp_packets -A INPUT -p icmp -j icmp_packets -A FORWARD -p icmp -j icmp_packets -A FORWARD -p tcp -j bad_tcp_packets -A FORWARD -m set --match-set USERS src -j ACCEPT -A FORWARD -m set --match-set USERS dst -j ACCEPT -A OUTPUT -p tcp -j bad_tcp_packets -A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset -A bad_tcp_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 2/sec -j ACCEPT -A bad_tcp_packets -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT -A icmp_packets -p icmp -m length --length 530:65535 -j DROP -A icmp_packets -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT -A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT -A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT COMMIT # Completed on Tue Feb 12 15:05:28 2013 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 12 февраля, 2013 · Жалоба Ну если до этого был линейный просмотр юзерских ip в iptables - то после замены на ipset картина должна разительно поменяться. А по контраку таки не согласен, любой маршрутизатор при его использовании раза в 2-3 больше ресурсов кушает(даже банальный модуль state как у ТСа, при больших размераз контрака это зло). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 февраля, 2013 · Жалоба Разрешите встрять в ваш разбор: мне кажется, что дело в шейпере. Судя по перфу - классификатор вылез на второе место. Это не есть хорошо, "при хешах такого не было"(с). Ну и попробуйте следующую стратегию по диагностике проблемы: начинает тупить, начинайте отключать сервисами: шейпер, фаер. Полностью. И ждите минуту примерно, потому что как заметили верно ранее - машина накапливает снежный ком и чтобы выйти из состоянния softirq нужно какое-то время. То есть в ту же секунду может не полегчать. Если будет тупить на простом роутинге, то надо менять ядро. Потому что первый в топе у перфа - _raw_spin_lock - это код ядра, который и является в вашем случае бутилочным горлышком. А вот кто зовет этот код - это вопрос, который, кстати, можно снова таки профайлером посмотреть. У меня как-то такое было на супер-глючном 2.6.32 ядре, которое такое вытворяло на 1-2 Мбит/с трафика в при использовании IPSec. Но в моем случае по профайлеру сразу стало ясно откуда ноги растут. После смены на 3.2.23 - всё стало замечательно. Новым ядрам старше - я пока не верю. Там какое-то феерическое количество граблей для роутеров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 14 февраля, 2013 · Жалоба Прикрутил хеши. Аптайм 10 часов. Вроде всё нормально. Только я одного понять не могу. Да, не было ipset, но правила группировались. Шейпер был линейным. НО старый сервер в несколько раз слабее нового и в принципе справлялся, а тут та же конфигурация правил, но при копеечной загрузке канала, процы в полку. Я бы ещё понял, если бы в perf вылазил бы в топ iptables или u32, а тут какой-то _raw_spin_lock. И появилась эта хрень не сразу, а спустя время. P.S.: зато наконец-то руки дошли до хешей :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...