aabc Опубликовано 22 декабря, 2014 (изменено) · Жалоба Dark_Angel Так как у драйвера есть предел размера очереди в 4096, то я советовал увеличить кол-во очередей в два раза, что по-сути увеличит очередь в два раза. При этом оказалось, что ixgbe оставляет векторов прерывания столько-же сколько cpu (то есть их в два раза больше не становится), по две очереди оказываются на одном прерывании. Это конечно от реализации драйвера зависит и не было предсказуемо. Но, если бы прерываний стало больше в два раза, то это всё равно нагрузка на [hard] irq, где она была небольшая. Грузило softirq. Это всё было в контексте решения роста rx_no_dma_resources (QPRDC). Системную причину, почему он рос так и не выяснили. То ли флуктуации трафика (к чему я склоняюсь), то ли ещё что. Проще оказалось попробовать решение (увеличение очереди) и посмотреть результат. Изменено 22 декабря, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 23 декабря, 2014 · Жалоба Dark_Angel однозначно уверен, что не драйвер и не ядро. Т.к. их не менял. При этом ITR крутил в сторону увеличения и это не помогло, хотя и немного снизило количество ошибок. Причиной же мне кажется именно нелинейность нагрузки от трафика. То есть реально в определенные короткие промежутки времени очереди успевали забиваться до момента прерывания. Ошибки начинали появляться при трафике >=7Гбит/с при усреднении за 30 секунд. То есть сказать, сколько точно трафика было в каждый квант времени между прерываниями я не могу. Однако количество ошибок вырастало скачкообразно на 0.8-1.2 ошибок за раз, то есть вероятнее всего в моменты локального всплеска трафика. Сейчас перегрузил вторую машинку с такими же параметрами (8 RSS, 4 MSI-X вектора) на ядре 2.6.32-431.29.2.el6.x86_64 (CentOS 6.5), соответственно завтра к ночи смогу сравнить разницу в нагрузке при разных ядрах и отсутствии ошибок. Ну или узнать, что на старом ядре это не помогает и буду обновлять ядро :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 23 декабря, 2014 · Жалоба Спасибо за объяснения, парни. А до какого значения вы крутили ITR? Потому как моя логика следующая: раз очередь переполняется и её размер уже максимален ( вы ведь поставили ring buffer в 4096? ), значит нужно выгребать её чаще, что можно сделать чаще прерываясь. Например, в 2 раза больше, чем прерывается, когда есть ошибки. То есть больше очередей в данной ситуации выглядит как хак. Не самый плохой, но тем не менее. Ну и да, похоже ошибки набегают от всплеска за промежуток замера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 23 декабря, 2014 · Жалоба У меня сейчас стоит 12000 прерываний на вектор. В случае автоматического подбора драйвером в ЧНН было около от 7 до 8 тысяч. При 12000 и 4х очередях ошибки сыпало так же, как и на 8000, может в чуть меньшем абсолютном значении, но порядок такой же был. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 24 декабря, 2014 · Жалоба А есть возможность сделать столько же очередей сколько было и сделать 24К на вектор и посмотреть результат? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 24 декабря, 2014 · Жалоба Да, сегодня в связи с выходом драйвера 3.23.2, буду переделывать и пробовать под последним ядром CentOS, заодно и попробую такой вариант. Кстати, ядро 2.6.32-431.29.2 с драйвером 3.22.3, 8 RSS, 4 IRQ, 12K на вектор - всё равно есть ошибки даже при пиковом трафике <7 гбит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 25 декабря, 2014 · Жалоба to junjunk2, если у вас два сервера NAT и есть локальная связанность внутри сети между клиентами то у вас еще будет паразитный торрент трафик между пулами белых адресов обоих серверов если так то прибейте его и получите еще несколько процентов cpu в бонус и еще, попробуйте включить rpf-check на железке отдающей траф в сторону nat сервера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 25 декабря, 2014 · Жалоба Dark_Angel Даже при 8 RSS увеличение прерываний до 20К не дало избавления от ошибок. и на ядре Centos в perf top вижу вот такое: 15.34% [kernel] [k] _spin_lock 9.22% [kernel] [k] ip_route_input 5.74% [kernel] [k] ixgbe_poll 5.13% [kernel] [k] native_read_tsc 3.91% [kernel] [k] delay_tsc с чего бы это вдруг _spin_lock вылез в отрыв?... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 25 декабря, 2014 · Жалоба на ядре Centos в perf top вижу вот такое: 15.34% [kernel] [k] _spin_lock 9.22% [kernel] [k] ip_route_input 5.74% [kernel] [k] ixgbe_poll 5.13% [kernel] [k] native_read_tsc 3.91% [kernel] [k] delay_tsc с чего бы это вдруг _spin_lock вылез в отрыв?... Делайте perf top -g (появится "+" в начале строк) потом ентером жмите на строчках, которые надо раскрыть. Будет такая же табличка тех функций кто вызывает _spin_lock с процентами. И там сверху будет виновник торжества. Например - 2.38% [kernel] [k] _raw_spin_lock - _raw_spin_lock + 41.78% sch_direct_xmit + 11.46% enqueue_to_backlog + 7.76% tick_do_update_jiffies64 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 декабря, 2014 · Жалоба Ну ошибок стало меньше/больше/так же? А когда 4 RSS очереди? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 26 декабря, 2014 · Жалоба Dark_Angel Не могу тут ничего сказать, т.к. ошибки ползут скачкообразно. Но порядок остался тот же - несколько сотен тысяч ошибок при 0.9 Mpps. 4 RSS пока еще не успел Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 26 декабря, 2014 · Жалоба Поскольку ядро не debug, то и perf top -g не может показать, откуда у каждого процесса ноги растут. Переход на ядро 2.6.32.504.3.3 и установка драйвера 3.23.2 под ixgbe, а так же 8 RSS и 12000 прерываний на вектор - ошибки исчезли. Итого, вероятнее всего в ядро 504 в ветке CentOS впили что-то от Mainline, связанное с conntrack (т.к. фактически больше ничего не используется), отчего производительность ната реально возрасла. Правда есть и побочный эффект - очень большое количество context switch, прямопропорциональное объему трафика (доходит до 22000 переключений в секунду). Причем на mainline ядре (правда 3.17.4) я такого не заметил (хоть там и было увеличение относительно 2.6.32.401, но значение не зависело от трафика и было стабильно около 2000 в секунду). Не думаю, что этому поспособствовал последний драйвер ixbge, но всё же поставлю на mainline этот драйвер для проверки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 27 декабря, 2014 (изменено) · Жалоба Поскольку ядро не debug, то и perf top -g не может показать, откуда у каждого процесса ноги растут. А.., в центосе чуть более старый perf и там надо делать: perf top -G Изменено 27 декабря, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 29 декабря, 2014 · Жалоба aabc Посмотрел, действительно -G показывает. Спасибо за подсказку. Однако сейчас ситуация нормальная и _spin_lock далеко не в топе. Проанализировал ситуацию - действительно, ядро 3.17 производительнее ядра 2.6.32.х, постовляемого в CentOS. Разница следующая - при абсолютно одинаковых процессорах, памяти и сетевых, абсолютно одинаковых настройках сетевых, количестве записей в таблице маршрутизации и в таблицах iptables, на последнем ядре от CentOS ветки 6 при 56% загрузки процессора пережевывается 6.2 ГБит/с, 860 Kpps, 810000 conntracks, при этом на ядре 3.17.4 при тех же 56% загрузки - 6.8 Гбит/с, 1.01 Mpps, 900000 conntracks. вот такая вот разница. Ошибок на интерфейсах нет уже 3 дня, причем не только обсуждаемых выше, но и других (кроме rx_csum_offload_errors, что насколько я понимаю, не является ошибкой производительности, а ошибкой среды передачи данных) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 30 декабря, 2014 · Жалоба Жаль, что не удалось проверить работу с 4 RSS, думаю ошибок тоже не будет при ручном ITR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 22 января, 2016 (изменено) · Жалоба Подниму темку. Поставили новый сервак - Xeon E5-1650 v2 + Intel X520-DA2. Собрал в LACP два порта. Отконфигурил всё как обычно на NAT серверах. В итоге при 15Гбит/с - 2.2 Mpps - почти все ядра в полке. Немного неравномерно были нагружены, но не суть. Вопрос - нормальный ли это показатель? У кого есть опыт по нагрузке? Так же параллельно при обновлении уже имевшихся серверов выявил интересную вещь - при включенных VT-x нагрузка значительно выше. При 5 Гбит/с 0.75 Мппс загрузка 34% на E3-1270 против 46% на абсолютно таком же железе с включенными VT-x. Причем intremap=off при загрузке ядра не помогает, надо именно отключить в BIOS. Ну и пока максимальную производительность показало ядро 3.19.3. По perf top с небольшим отрывом идет fib_table_lookup ... не нашел информации, включили ли патчик от Alexander Duyck " fib_trie: Reduce time spent in fib_table_lookup by 35 to 75%" в ванильные ядра, кто-нибудь владеет данной информацией? Изменено 24 января, 2016 пользователем junjunk2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 января, 2016 · Жалоба junjunk2 а чё, git log отменили? да, включили https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e495f78d787b56ad249946b191406f4521b58150 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 24 января, 2016 · Жалоба Спасибо, что направили в нужное место. Эти патчи не попали в 3.19.х, т.к. опоздали на сутки в net-next, в итоге перешел на 4.1.16, получил еще чуть ускорения. Итого на E3-1270v2 @3.5Ггц при 7.6 Гбит/с 1.15Mpps получаем ~55% нагрузки, ошибок на интерфейсе нет. Использовал пока что один порт от X520-DA2, сегодня еще попробую затестить ядро, пересобранное с опцией MCORE2, а на следующей неделе попробую запустить 2 порта и посмотреть, какой overhead будет у bonding и сколько вообще трафика может пережевать такое железо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 25 января, 2016 · Жалоба Провел еще тесты. overhead от подключения второго порта и сбора LACP какой-то очень уж большой - порядка 15%, соответственно при 12Гбит/с @ 1.8Mpps нагрузка 98-100%. Закралось смутное подозрение, что не совсем оптимально пакет обрабатывается. В моей схеме физичексие порты объединены в LACP, а in и out интерфейсы - это разные vlan поверх этого LACP. Есть подозрение, что пакет уходит не через ту очередь, через которую пришел, из-за выбора физического интерфейса в bonding. Есть ли у кого-нить опыт тюнинга таких вещей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 25 января, 2016 · Жалоба М.б. стоит попробовать без LACP? Через один физический пришло, через другой ушло? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 25 января, 2016 · Жалоба Hawk128 тогда я уткнусь в 10Гбит на линке Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 26 января, 2016 · Жалоба Действительно. А сейчас на вход 12 а на выход сколько проходит. В вашем случае они суммируются. И параметры слота и карты при загрузке на 8х заводятся? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
junjunk2 Опубликовано 26 января, 2016 (изменено) · Жалоба сейчас получается 12 в пике full duplex, соотношение 1/6 - tx, 5/6 - rx. То есть rx примерно 10 гбит/с в пике. при старте карта заводится как PCIe x8 ixgbe 0000:02:00.0: PCI Express bandwidth of 32GT/s available ixgbe 0000:02:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe 0000:02:00.0 eth0: MAC: 2, PHY: 18, SFP+: 5, PBA No: E66560-002 ixgbe 0000:02:00.0: 00:1b:21:6b:8c:20 ixgbe 0000:02:00.0 eth0: Enabled Features: RxQ: 8 TxQ: 8 FdirHash ixgbe 0000:02:00.0 eth0: Intel® 10 Gigabit Network Connection ixgbe: Direct Cache Access (DCA) set to 1 ixgbe: Receive-Side Scaling (RSS) set to 8 ixgbe: Interrupt Throttling Rate (ints/sec) set to 12000 ixgbe: Flow Director packet buffer allocation set to 3 ixgbe: 0000:02:00.1: ixgbe_check_options: Flow Director will be allocated 256kB of packet buffer ixgbe: Enabled/Disable FCoE offload Disabled ixgbe: 0000:02:00.1: ixgbe_check_options: FCoE Offload feature disabled ixgbe: LRO - Large Receive Offload Disabled ixgbe: allow_unsupported_sfp Enabled Изменено 26 января, 2016 пользователем junjunk2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 26 января, 2016 · Жалоба Hawk128 тогда я уткнусь в 10Гбит на линке Раскидайте нагрузку сегментацией либо роутингом, либо l2(vlan)+роутинг. Не надо никаких LACP - никогда профита от этой дряни не было... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 26 января, 2016 · Жалоба к слову, включение LRO может помочь еще немного выжать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...