[aabc]

К слову, по поводу разницы в версиях драйверов в upstream ядре и интеловских с sourceforge.

 

Вчера смотрел как драйвер карты igb передает регистры в ethtool. Так вот, интеловский драйвер igb-5.2.15 от 2014-11-26 с sourceforge, не передает регистры для очередей 4-15, в то время как драйвер в ядре имеет этот код ещё с Feb 15 2012. Вот вам и где новее.

[junjunk2]

aabc

Я специально сравнил драйвера оригинальные с Интела 3.19.2 и CentOS 3.19.2-k для ядра 2.6.32-504 - ощущение, что абсолютно разный код. Там не просто несколько фиксов наложили, а реально очень сильно изменили внутренности. Так что действительно не совсем понятно, что лучше. Но по настройке параметров лидер пока что именно с сайта интела.

[NiTr0]

То есть для роутера/ната лучше старая 486тушка, а не современный 8ядерный комп с 10G интеловыми карточками?

А причем одно к другому? Ядро там достаточно свежее (всяко свежее центоса, который активно юзают на роутинге).

 

NiTr0, сейчас цена ssd пренебрежительно мала, не вижу никакого смысла экономить на этом.

У вас никогда не было проблем с крашем подмонтированного раздела при внезапно отключении питания? У вас никогда не дохли SSD опять же при отключении питания во время записи?

А главное - нафига держать постоянно смонтированный раздел там, где он нафиг не нужен?

Не, можно конечно заняться извращением и приживить обычный дистр в режиме рид-онли корня (доводилось такое делать там, где нужно было много всякого софта) - но нафига?

 

Хотя не спорю, если есть время и люди, которые способны напилить туда драйверов (из описания я так понял, для интелловских карточек есть только e1000e и igb более-менее свежие), то возможно и будет прирост... Но имхо - это еще гемморойнее, нежели Gentoo. И опять же боязно в продакшн ставить такой сборник...

Напилить - 5 минут дела. И всяко быстрее, чем апдейтить генту, которая не апдейтилась эдак год-другой. Это если хочется пособирать самого свежего, т.к. драйвер igb из ядра там вполне себе включен и готов к использованию, и в 3.10.60 (или какое там в 5.1.2) он не такой уж и древний.

[junjunk2]

NiTr0

Ну тут речь о драйвере ixgbe, который для 10Гбит карт, и его я при быстром просмотре там не увидел.

[NiTr0]

Ну тут речь о драйвере ixgbe, который для 10Гбит карт, и его я при быстром просмотре там не увидел.

Опечатался, да:

 

# ls -l
итого 44
drwxr-xr-x 2 root root  4096 ноя 28 19:29 e1000
drwxr-xr-x 2 root root  4096 ноя 28 19:41 e1000e
-rw-r--r-- 1 root root 18471 ноя 28 19:29 e100.ko.gz
drwxr-xr-x 2 root root  4096 ноя 28 20:49 igb
drwxr-xr-x 2 root root  4096 ноя 28 19:29 ixgb
drwxr-xr-x 2 root root  4096 ноя 28 19:29 ixgbe
drwxr-xr-x 2 root root  4096 ноя 28 19:29 ixgbevf

[junjunk2]

NiTr0

А можете кинуть modinfo для ixgbe из этого дистрибутива?

[Tamahome]

NiTr0,на ssd сейчас только новые конфигурации будут переходить,по причине того, что дешевле винтов пошли, а по обычным винтам статистика вполне годная, проблем из-за краха фс после передёргивания питания не было. Винты дохли, бывало, но не после питания, дохло в процессе работы, обычно оно тупо работало с тем, что осталось в памяти, и спокойно дожидалось замены, сейчас это решено заменой на mdraid, но винты уж год как не дохнут совсем, винты совершенный ширпотреб-сегейт.

Да и что на них писать роутеру? Условия работы чердачно-подвальные, с говном голубей и температурой в помещении -40 +40+

Апдэйты не вызывают проблем, софта на роутере мало, никаких ненужных зависимостей и прочего гемороя. Железо разное, образ один.

Постоянно подмонтированый корень не напрягает никак.

[junjunk2]

итак, вернемся к начальной проблеме. сейчас вот так всё:

Птн Дек 5 12:22:33 MSK 2014 rx_no_dma_resources: 453633 tx_restart_queue: 0
12:24:17 up 1 day,  5:11,  2 users,  load average: 0.00, 0.01, 0.05
3.17.4-1.el6.elrepo.x86_64
driver: ixgbe
version: 3.22.3
Current hardware settings:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096

 

все ошибки вылезли в ЧНН, но понять, в чем именно затыкается машина - не могу. Максимальная нагрузка в ЧНН - 65%

у кого какие мысли есть, куда еще рыть?

[NiTr0]

А можете кинуть modinfo для ixgbe из этого дистрибутива?

# modinfo ixgbe
filename:       ixgbe.ko.gz
license:        GPL
author:         Intel Corporation, <linux.nics@intel.com>
description:    Intel(R) 10 Gigabit PCI Express Network Driver
version:        3.13.10-k
alias:          pci:v00008086d00001560sv*sd*bc*sc*i*
alias:          pci:v00008086d00001557sv*sd*bc*sc*i*
alias:          pci:v00008086d0000154Dsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F8sv*sd*bc*sc*i*
alias:          pci:v00008086d00001529sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F9sv*sd*bc*sc*i*
alias:          pci:v00008086d00001507sv*sd*bc*sc*i*
alias:          pci:v00008086d00001517sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F7sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010E1sv*sd*bc*sc*i*
alias:          pci:v00008086d000010ECsv*sd*bc*sc*i*
alias:          pci:v00008086d0000150Bsv*sd*bc*sc*i*
alias:          pci:v00008086d000010C7sv*sd*bc*sc*i*
alias:          pci:v00008086d000010B6sv*sd*bc*sc*i*
srcversion:     BE56736D2DDC912CA89522F
depends:        mdio,hwmon,ptp,dca
vermagic:       3.10.57-i686 SMP mod_unload modversions 686 
parm:           debug:Debug level (0=none,...,16=all)
parm:           allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599-based adapters
parm:           max_vfs:Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63

 

проблем из-за краха фс после передёргивания питания не было

А у меня бывали на обычных серверах.

 

Винты дохли, бывало, но не после питания,

Винты от пропадания питания и не будут дохнуть,м аксимум - бэд-сектор вылезет (если сектор недописался). SSD - совсем другая песня. И у них помимо обычного внутреннего wear-leveling для свежезаписаных данных (когда перезапись идет в новые блоки) еще есть и фоновые сбощики мусора/фоновый wear-leveling, в процессе которого данные перемещаются со старого места, на котором они "залежались" (которое давно не переписывалось), на новое, для более равномерного износа. Сбой по питанию при этом может иметь весьма печальные последствия - SSD порушит структуру своей служебной зоны, и превратится в тыкву. Ну примерно как USB флэшка, если ее выдернуть в процессе записи.

 

Да и что на них писать роутеру?

Немного, но пишется. Логи к примеру.

 

Постоянно подмонтированый корень не напрягает никак.

Ну тут уже дело ваше. Хочется ставить SSD - ставьте, а мне к примеру спокойнее когда система гарантированно загрузится в том же виде, в каком она в последний раз сохранялась на флэшку, что бы ни произошло после этого (хоть rm -rf / из-за ошибки в каком-то скрипте или ошибки диспетчера, хоть многократные пропадания питания, хоть еще что). И бекап раскатывается 5 минут.

[SyJet]

А можете кинуть modinfo для ixgbe из этого дистрибутива?

# modinfo ixgbe
filename:       ixgbe.ko.gz
license:        GPL
author:         Intel Corporation, <linux.nics@intel.com>
description:    Intel(R) 10 Gigabit PCI Express Network Driver
version:        3.13.10-k
alias:          pci:v00008086d00001560sv*sd*bc*sc*i*
alias:          pci:v00008086d00001557sv*sd*bc*sc*i*
alias:          pci:v00008086d0000154Dsv*sd*bc*sc*i*
alias:          pci:v00008086d000010F8sv*sd*bc*sc*i*
alias:          pci:v00008086d00001529sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F9sv*sd*bc*sc*i*
alias:          pci:v00008086d00001507sv*sd*bc*sc*i*
alias:          pci:v00008086d00001517sv*sd*bc*sc*i*
alias:          pci:v00008086d000010F7sv*sd*bc*sc*i*
alias:          pci:v00008086d000010DBsv*sd*bc*sc*i*
alias:          pci:v00008086d000010E1sv*sd*bc*sc*i*
alias:          pci:v00008086d000010ECsv*sd*bc*sc*i*
alias:          pci:v00008086d0000150Bsv*sd*bc*sc*i*
alias:          pci:v00008086d000010C7sv*sd*bc*sc*i*
alias:          pci:v00008086d000010B6sv*sd*bc*sc*i*
srcversion:     BE56736D2DDC912CA89522F
depends:        mdio,hwmon,ptp,dca
vermagic:       3.10.57-i686 SMP mod_unload modversions 686 
parm:           debug:Debug level (0=none,...,16=all)
parm:           allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599-based adapters
parm:           max_vfs:Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63

 

проблем из-за краха фс после передёргивания питания не было

А у меня бывали на обычных серверах.

 

Винты дохли, бывало, но не после питания,

Винты от пропадания питания и не будут дохнуть,м аксимум - бэд-сектор вылезет (если сектор недописался). SSD - совсем другая песня. И у них помимо обычного внутреннего wear-leveling для свежезаписаных данных (когда перезапись идет в новые блоки) еще есть и фоновые сбощики мусора/фоновый wear-leveling, в процессе которого данные перемещаются со старого места, на котором они "залежались" (которое давно не переписывалось), на новое, для более равномерного износа. Сбой по питанию при этом может иметь весьма печальные последствия - SSD порушит структуру своей служебной зоны, и превратится в тыкву. Ну примерно как USB флэшка, если ее выдернуть в процессе записи.

 

Да и что на них писать роутеру?

Немного, но пишется. Логи к примеру.

 

Постоянно подмонтированый корень не напрягает никак.

Ну тут уже дело ваше. Хочется ставить SSD - ставьте, а мне к примеру спокойнее когда система гарантированно загрузится в том же виде, в каком она в последний раз сохранялась на флэшку, что бы ни произошло после этого (хоть rm -rf / из-за ошибки в каком-то скрипте или ошибки диспетчера, хоть многократные пропадания питания, хоть еще что). И бекап раскатывается 5 минут.

Вот бы вы еще инсталлер написали для него, с удовольствием бы юзал ваш дистрибутив... Чесслово, не все имеют нужный объем знаний для его инсталяции, я к примеру так и не смог его поставить. А очень хотелось бы.

[NiTr0]

Вот бы вы еще инсталлер написали для него

 

Распаковать на флэшку, и сделать ее системной через syslinux 4.x (syslinux -s /dev/sdX)... По-моему, инсталлятор для такого действия излишний :)

[aabc]

у кого какие мысли есть, куда еще рыть?

 

Можно ещё попробовать увеличивать эти переменные в разы:

 

dev_weight

--------------

 

The maximum number of packets that kernel can handle on a NAPI interrupt,

it's a Per-CPU variable.

Default: 64

 

netdev_budget

-------------

 

Maximum number of packets taken from all interfaces in one polling cycle (NAPI

poll). In one polling cycle interfaces which are registered to polling are

probed in a round-robin manner.

Default: 300

 

netdev_max_backlog

------------------

 

Maximum number of packets, queued on the INPUT side, when the interface

receives packets faster than kernel can process them.

Default: 1000

Изменено 6 декабря, 2014 пользователем aabc

[SyJet]

Вот бы вы еще инсталлер написали для него

 

Распаковать на флэшку, и сделать ее системной через syslinux 4.x (syslinux -s /dev/sdX)... По-моему, инсталлятор для такого действия излишний :)

Винда и виртуалка в этом деле не помошники как я понял ))

А было бы супер все же....

[junjunk2]

aabc

а до каких пределов крутить? увеличение в 4 раза особых результатов не дало

[NiTr0]

Винда и виртуалка в этом деле не помошники как я понял ))

syslinux есть и для винды, а в виртуалке все вполне разворачивается с iso образа (ну или пользуется с iso образа).

[aabc]

junjunk2

Уверены? Попробуйте в 10. И покажите /proc/net/softnet_stat

Изменено 7 декабря, 2014 пользователем aabc

[junjunk2]

aabc

 

счас проанализировал ситуацию - трафика было заметно больше, за 8гбит/с перевалило, а ошибок стало меньше, т.к. раньше было порядка 400к ошибок за ЧНН, то вчера было всего лишь 280к при бОльшем трафике. В 10 раз попробую этой ночью.

 

[root@nat ~]# cat /proc/net/softnet_stat

c3ef4378 00000000 0004a560 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

98dec436 00000000 0004aa89 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

c3675ef8 00000000 0004881f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

b5b97874 00000000 0005250b 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

[aabc]

[root@nat ~]# perf stat -a -e cache-misses,cache-references sleep 10

 

Performance counter stats for 'sleep 10':

 

143,932,141 cache-misses # 19.205 % of all cache refs [100.00%]

749,470,404 cache-references

 

10.000898990 seconds time elapsed

 

Потестировал ради смеха научного интереса влияние разных сочетаний rss, rps, xps на cache-misses%. Кернел 3.14.23, кэш 32K+32K, 256K, 12288K, 8 ядер. igb 8 очередей, router+nat.

 

1. rss, rps, xps отключены:

     13,308,975 cache-misses # 5.607 % of all cache refs

2. rss, rps, xps включены и настроены все на одинаковые ядра (скажем, очередь 1 на cpu1, очередь 2 на cpu2 и тд.):

     7,569,202 cache-misses # 6.286 % of all cache refs

3. rss, xps включены и настроены все на одинаковые ядра, rps отключен:

     7,959,087 cache-misses # 6.495 % of all cache refs

4. rss, rps, xps включены и настроены все на разные ядра (пример, очередь 1: rss на cpu1, rps на cpu2, xps на cpu3, и тд.):

     13,938,683 cache-misses # 19.741 % of all cache refs

5. rss на одно ядро, rps, xps на другое, но одинаковое между собой:

     13,745,772 cache-misses # 18.587 % of all cache refs

6. rss, xps на одном ядре, rps на другом:

     11,015,673 cache-misses # 13.744 % of all cache refs

 

Выводы такие: RSS и RPS одновременно включать - можно, вреда нет; положительный эффект от того, что всё на одинаковом проце действительно есть.

Изменено 8 декабря, 2014 пользователем aabc

[Dark_Angel]

Главный вопрос: зачем включать RPS, если есть RSS?

[aabc]

Главный вопрос: зачем включать RPS, если есть RSS?

Можно им не заморачиваться если знать, что одно другому не мешает. (В теории помешать может, на других картах/драйверах, но вот на моих нет.)

[Dark_Angel]

Ну это сомнительное утверждение. Пока всё работает - это, возможно, и не важно. Но как только начнутся проблемы, понять что и как обрабатывается будет сложнее. Поэтому, по-моему лучше выключать RPS/XPS если о не нужен.

 

Я придумал только одно исключение - это терминирование туннелей. Туннели нормально RSS не обрабатываются в современных сетевых картах, поэтому нужно включать RPS, чтобы это хоть как-то было не на одно ядро. В этом случае нормальные пакеты и деинкапсулированные пакеты будут разруливаться картой, а туннели RPS/XPS.

[aabc]

Ну, xps тут вообще ни при чём. Он нужен для размазывания tx нагрузки по ядрам. По умолчанию (на том же 3.14.23) tx почему-то идёт в одну очередь, что грузит ядра неравномерно. Ну а выбор между rss и rps, дело вкуса. Дока пишет так:

 

For a multi-queue system, if RSS is configured so that a hardware

receive queue is mapped to each CPU, then RPS is probably redundant

and unnecessary. If there are fewer hardware queues than CPUs, then

RPS might be beneficial if the rps_cpus for each queue are the ones that

share the same memory domain as the interrupting CPU for that queue.

 

То есть они не запрещают включать RSS и RPS одновременно, просто это как бы не нужно. RPS может понадобиться чтоб включить Flow Limit, для защиты от DoS.

[Dark_Angel]

Я обратного и не утверждал.

 

"Поэтому, по-моему лучше выключать RPS/XPS если о не нужен."

 

В моем примере выше, XPS нужен для размазывания очередей отправки пакетов для туннелированных пакетов. Штатный RSS свалит всё в одну чередь.

Изменено 8 декабря, 2014 пользователем Dark_Angel

[junjunk2]

Наконец-то смог вернуться к проблеме, по совету aabc увеличил количество очередей, сделал их больше, чем количество физических ядер, в итоге ошибки ушли полностью. работа ядра 3.17 с nf_conntrack действительно намного лучше, поэтому остановлюсь именно на этом ядре. всё остальное осталось как в старом стабильном CentOS, соответственно работает железобетонно, запас по производительности показывает, что 9+ Гбит/с однозначно машинка протянет, включать второй порт на этом железе смысла нет, т.к. в пике более 12-13 гбит не получится, а еще один порт на 10 гбит можно использовать и более эффективно.

[Dark_Angel]

Так а вы уверены, что именно увеличение количества очередей является решением, а не ядро и драйвер, например?

 

Ну и если ответ да, то, мне кажется, что-то тут не так. Очереди у вас гибридные? Если да, то их увеличение больше количества процессоров только увеличивает оверхед. Может тогда нужно ITR руками подкрутить, чтобы чаще выгребать буфера карт?