pavel.odintsov Опубликовано 12 июня, 2012 · Жалоба Приветствую всех! Имеется linux софтроутер (debian, 2.6.39-bpo.2-amd64) с 3мя сетевыми Intel 82574L в бондинге, используется для терминации вланов, собственно роутинга, нетфлоу (ipt_NETFLOW 1.7.1) и квагги. Платформа собрана на DQ67OW + i7 2600 (4 ядра). Проектная пропускная способность роутинга около 500k pps и 3-4 гигабита. Некоторе время назад вся эта радость от 45к pps UDP флуда в канал (около 40 мегабит полосы) ушла в даун, с потерями до 70% и примерно следующей картиной в top: top - 19:44:15 up 3:27, 4 users, load average: 4.57, 4.71, 4.25 Tasks: 122 total, 5 running, 117 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 62.5%id, 0.0%wa, 0.0%hi, 37.5%si, 0.0%st Mem: 16388968k total, 1551048k used, 14837920k free, 22372k buffers Swap: 15623032k total, 0k used, 15623032k free, 76604k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10657 root 20 0 0 0 0 R 93 0.0 4:35.97 kworker/0:1 19 root 20 0 0 0 0 R 86 0.0 24:09.85 ksoftirqd/3 10 root 20 0 0 0 0 R 83 0.0 24:55.80 ksoftirqd/1 9 root 20 0 0 0 0 R 14 0.0 5:30.97 kworker/1:0 187 root 20 0 0 0 0 S 13 0.0 4:33.62 kworker/3:1 3 root 20 0 0 0 0 R 7 0.0 46:51.54 ksoftirqd/0 12 root RT 0 0 0 0 S 4 0.0 0:15.51 watchdog/1 20 root RT 0 0 0 0 S 0 0.0 0:10.22 watchdog/3 11497 root 20 0 68460 3256 2568 S 0 0.0 0:00.04 sshd 11537 root 20 0 19660 1584 1076 S 0 0.0 0:00.05 htop 1 root 20 0 8400 812 676 S 0 0.0 0:01.81 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd 4 root 20 0 0 0 0 S 0 0.0 24:36.66 kworker/0:0 6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0 7 root RT 0 0 0 0 S 0 0.0 15:16.83 watchdog/0 8 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1 13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2 14 root 20 0 0 0 0 S 0 0.0 0:00.27 kworker/2:0 15 root 20 0 0 0 0 S 0 0.0 0:00.03 ksoftirqd/2 16 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/2 17 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3 18 root 20 0 0 0 0 S 0 0.0 0:00.06 kworker/3:0 21 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/4 22 root 20 0 0 0 0 S 0 0.0 0:00.16 kworker/4:0 23 root 20 0 0 0 0 S 0 0.0 0:00.13 ksoftirqd/4 Настройки сетевых идентичны и выглядят следующим образом: ethtool -k ethX Offload parameters for ethX: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ntuple-filters: off receive-hashing: off Вот такая картина по дропу пакетов: bond0 Link encap:Ethernet HWaddr 00:1b:21:cf:9e:de inet6 addr: fe80::21b:21ff:fecf:9ede/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:964183049 errors:0 dropped:443102763 overruns:0 frame:0 TX packets:969736063 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:356965185173 (332.4 GiB) TX bytes:367494617224 (342.2 GiB) eth1 Link encap:Ethernet HWaddr 00:1b:21:cf:9e:de UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:362632849 errors:0 dropped:178313485 overruns:0 frame:0 TX packets:447222062 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:135986998561 (126.6 GiB) TX bytes:282556935627 (263.1 GiB) Interrupt:16 Memory:fbbc0000-fbbe0000 eth2 Link encap:Ethernet HWaddr 00:1b:21:cf:9e:de UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:471814605 errors:0 dropped:87155543 overruns:0 frame:0 TX packets:155805387 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:209507086038 (195.1 GiB) TX bytes:47642570198 (44.3 GiB) Interrupt:16 Memory:fbac0000-fbae0000 eth4 Link encap:Ethernet HWaddr 00:1b:21:cf:9e:de UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:129735595 errors:0 dropped:177612653 overruns:0 frame:0 TX packets:366708614 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11471100574 (10.6 GiB) TX bytes:37295111399 (34.7 GiB) Interrupt:16 Memory:fb9c0000-fb9e0000 Картинка по прерываниям следующая (уже в процессе атаки пораскидывали их по ядрам, но это не сильно помогло): cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 773 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 2 0 0 0 0 0 0 0 IO-APIC-edge i8042 5: 0 0 0 0 0 0 0 0 IO-APIC-edge parport0 6: 2 0 0 0 0 0 0 0 IO-APIC-edge floppy 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 12: 4 0 0 0 0 0 0 0 IO-APIC-edge i8042 16: 407 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ata_generic 23: 32 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 40: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 41: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 42: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 43: 1238070 0 0 0 0 0 0 0 PCI-MSI-edge eth0 44: 553414 0 0 0 0 0 0 0 PCI-MSI-edge ahci 45: 10730545 210826225 0 0 0 0 0 0 PCI-MSI-edge ???? 46: 370959469 0 0 0 0 0 0 0 PCI-MSI-edge 47: 77171814 0 33886984 0 0 0 0 0 PCI-MSI-edge eth1 48: 11913520 0 0 298641954 0 0 0 0 PCI-MSI-edge ???? 49: 112459281 0 0 0 0 0 0 0 PCI-MSI-edge ???? 50: 42894808 201422 0 0 0 9106811 0 0 PCI-MSI-edge eth2 51: 25624993 0 0 0 0 0 0 0 PCI-MSI-edge ???? 52: 117353778 0 0 0 61270868 0 0 0 PCI-MSI-edge ???? 53: 74602277 0 0 0 0 0 25465618 0 PCI-MSI-edge eth4 54: 243 0 0 0 0 0 0 0 PCI-MSI-edge hda_intel 55: 2 0 0 0 0 0 0 0 PCI-MSI-edge i915 NMI: 12101 30303 1293 36266 1859 976 20613 504 Non-maskable interrupts LOC: 13100616 14557779 1443510 13385411 2336580 2836769 11029251 2726259 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 12101 30303 1293 36266 1859 976 20613 504 Performance monitoring interrupts IWI: 0 0 0 0 0 0 0 0 IRQ work interrupts RES: 319630 25336 49492 28580 19966 16016 9775 999 Rescheduling interrupts CAL: 2915 72901 211260 178895 219933 208775 407697 295597 Function call interrupts TLB: 150 347 169 641 2365 4698 4469 1815 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 732 732 732 732 732 732 732 732 Machine check polls ERR: 0 MIS: 0 Итого, списали проблему на то, что не справилось железо (хотя подозрения, конечно, есть на то, что netflow съел весь процессор) и решили устроить роутеру апгрейд, как раз по нему и вопросы. Для начала планируем заменить сетевую 82574 на что-то более серьезное, среди вариантов рассматриваются Intel PT (82571), Intel ET (82576) или Intel l340 (82580). Хотелось бы услышать рекомендацию по поводу поведения данных карточек под серьезной нагрузкой. Среди глобальных планов на относительно близкое будущее расссматривается замена socket1155+i7 2600 на что-то более серьезное, пока присматриваемся к LGA 2011 и i7 3930, радует наличие большого числа PCI-e, 4х канальная память и в целом большая производительность. Но есть мысли в сторону двухпрцоессорных конфигураций. Хотелось бы услышать рекомендации по поводу платформ под нашу нагрузку. Заранее спасибо за внимание и ответы! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 июня, 2012 · Жалоба 82576 ставьте, 82580 не особо от нее отличается. И я сомневаюсь, что вам скоро понадобится апгрейдить вашу железку. Скорее - правила иптейблс подтюнить, сетевую подсистему... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 12 июня, 2012 (изменено) · Жалоба 82576 минимум. Хотя - если пока менять возможности нет - в сторону RPS посмотрите, оно может спасти под пиковыми нагрузками. А вот 45kpps UDP-флуда, завалившего машину - явление странное. Сами сетевки тут вряд ли при чём. Очень вероятно, что какой-то броадкаст, пролетающий весь стек вплоть до userspace. Изменено 12 июня, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 июня, 2012 · Жалоба Тут небольшое дорасследование провели, похоже, напортолись на spin-lock в ipt_NETFLOW 1.7.1 в связке с 2.6.39м ядром, как раз в момент атаки вылетело пару стек-трейсов именно из кода отвечающего за блокировки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 12 июня, 2012 · Жалоба 82576 ставьте, 82580 не особо от нее отличается. И я сомневаюсь, что вам скоро понадобится апгрейдить вашу железку. Скорее - правила иптейблс подтюнить, сетевую подсистему... Поддерживаю. Я бы поставил 10G карту, ибо бондинг сам по себе на высоких скоростях затратратное дело. Легкий тюнинг и на существующем железе все прокачает. Кстати, вполне возможно бондинг вкупе с другими "отягчающими" Вас и подвел. В свое время от него как отказались, сразу легче стало. в сторону RPS посмотрите, оно может спасти под пиковыми нагрузками. Не согласен. Игрался я тут с RPS в различных комбинациях, не помогает особо. Сам RPS затратное в части ресурсов дело. Если чистый роутинг, без терминации PPP, то лучше без него! Ванильное 32-е ядро реально рулит. ЗЫ У Вас 39-е ядро, оно само по себе своеобразное. Попробуйте 32-е или 3-ю ветку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 12 июня, 2012 (изменено) · Жалоба Если чистый роутинг, без терминации PPP, то лучше без него Странно, у меня абсолютно противоположный опыт. Есть в одном месте Core 2 Quad 2.8 (так уж получилось), две набортных 82574L + две внешних таких же. CentOS 6, ядро слегка пофикшено (в "ванильном" RHEL'овском ядре есть мелкоглюк в RPS, из-за коего он начнёт работать только в 6.3). 1.5 гига трафа "насквозь" в обе стороны, ~200Kpps, 2 группы LACP по 2 порта, чистый роутинг + BGP. Если не включать RPS - всплески по интерфейсам иногда приводят к потере пакетов на 82574L и джиттеру поряка 1-2 мс в часы пик. Если включить - в те же часы пик никаких потерь нет, джиттер порядка 0.1-0.5мс. Это при том, что 4 карточки строго прибиты к ядрам. Т.е. очевидно, в какие-то моменты одно ядро по одной из карточек не справляется, и разброс по ядрам помогает. Увеличение нагрузки от RPS - в пределах 1-3%. sysctl'ы выкручены следующим образом: net.core.dev_weight = 16net.core.netdev_budget = 256 net.core.netdev_max_backlog = 16000 net.core.netdev_tstamp_prequeue = 0 Если интересно, и готовите где-нибудь RPS - попробуйте обратить внимание на параметр net.core.netdev_tstamp_prequeue = 0. По моей статистике, именно значение по умолчанию (1) даёт рост нагрузки от RPS. Изменено 12 июня, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 12 июня, 2012 · Жалоба Вот по поводу 2.6.39 тоже есть сомнения в его "странности", это было настроено до меня и, честно говоря, убедительных доводов, почему именно 2.6.39 (из бэкпортов дебияна и ныне почившего вообще) у меня не имеется. Интересует стабильность работы ipt_NETFLOW 1.7.1 в связке с 2.6.32 (правда, не ваниальным, а дебияновским). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 июня, 2012 (изменено) · Жалоба У меня ipt_NETFLOW работает на центосовском ядре (2.6.32 от редхата) как раз на пресловутом Core 2, о котором выше писал, без проблем. Правда, версию навскидку не помню, как погляжу - добавлю в сообщение. Поглядел. Ядро от C6.2, 82574L, RPS, bonding, BIRD, ipt_NETFLOW 1.7.1. Проблем не отмечено. Изменено 13 июня, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 июня, 2012 · Жалоба Alex/AT, огромное спасибо за ценную информацию! Будем откатываться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 13 июня, 2012 · Жалоба Покуда бодались с netflow появилась идея, а не заменить ли netflow на бордер роутере на port mirroring на D-Link DGS-3120 + отдельный дивайс для анализа трафика, таким образом роутер станет чисто руотером без наворотов. Есть какие-либо подводные камни у такой схемки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 июня, 2012 (изменено) · Жалоба Alex/AT, огромное спасибо за ценную информацию! Будем откатываться. Если будете юзать центосовское ядро - там надо фиксить RPS, оно не работает в 6.1-6.2. Патч с фиксом RPS и некоторой оптимизацией сетевого стека можно забрать здесь: http://alex-at.ru/media/blogs/alex/Code/Kernel/2.6.32-220.7.1.alex.rps.2.patch Изменено 13 июня, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
iMPoSsibLe_iT Опубликовано 15 июня, 2012 · Жалоба Доброго времени суток уважаемый all. Хотел поинтересоваться использует ли кто-нибудь сетевушки на чипе 82599ES в продакшене. Присматриваюсь к вот такой карточке: ftp://ftp.supermicro.com/CDR-NIC_1.22_for_Add-on_NIC_Cards/MANUALS/datasheet-AOC-STGN-i2S.pdf Есть ли грабли в использовании? Или может посоветуете аналоги с 1-2 портами sfp+ Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cpulink Опубликовано 15 июня, 2012 · Жалоба Доброго времени суток уважаемый all. Хотел поинтересоваться использует ли кто-нибудь сетевушки на чипе 82599ES в продакшене. Присматриваюсь к вот такой карточке: ftp://ftp.supermicro...OC-STGN-i2S.pdf Есть ли грабли в использовании? Или может посоветуете аналоги с 1-2 портами sfp+ Спасибо. Совсем недавно поставили Intel X520-DA2 2 sfp+ порта, и 1 сфп+ 10G, тестим. 8 дней. Трафик гоняется где-то 2,5 Гига туда-сюда. Драйвер пришлой собирать самим, т.к. с сфп+ (не от интел) не хотел работать. Ядро 3.3.8, на 3.4 драйвер вроде уже с нужными опциями и патчами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 19 июня, 2012 (изменено) · Жалоба Тесты подтвердили, что виноват-то был ipt_netflow. С ipt_netflow все начинало лежать где-то с 50 kpps вот с такой картиной в perf top: PerfTop: 1864 irqs/sec kernel:99.7% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ______________________________ ________________________________________________________________________ 839.00 11.1% netflow_target [ipt_NETFLOW] 535.00 7.1% ipt_do_table /lib/modules/2.6.39-bpo.2-amd64/kernel/net/ipv4/netfilter/ip_tables.ko 396.00 5.2% _raw_spin_lock [kernel.kallsyms] 352.00 4.7% e1000_clean_rx_irq /lib/modules/2.6.39-bpo.2-amd64/kernel/drivers/net/e1000e/e1000e.ko Без него почти стабильно держится 100-120 kpps: PerfTop: 1764 irqs/sec kernel:99.5% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ______________________________ ________________________________________________________________________ 398.00 7.2% e1000_clean_rx_irq /lib/modules/2.6.39-bpo.2-amd64/kernel/drivers/net/e1000e/e1000e.ko 311.00 5.7% acpi_os_read_port [kernel.kallsyms] 284.00 5.2% ipt_do_table /lib/modules/2.6.39-bpo.2-amd64/kernel/net/ipv4/netfilter/ip_tables.ko Изменено 19 июня, 2012 пользователем pavel.odintsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 20 июня, 2012 · Жалоба Попробуйте размер хеша увеличить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...