[dazgluk]

В ядре 3.6 как минимум выпилен Route Cache.

 

Dark_Angel Соглашусь про ITR, видимо в пограничных состояниях, когда 70K IRQ уже много, а 40K еще мало, куча дропов и появлялось.

При раздутии буферов, судя по http://comments.gman...000.devel/11667, в худшем случае пакет пройдет за 0.5мс, считаю это приемлемым, пара сотых процента packet loss мне кажется заметнее.

 

AABC, а разве в результате этого тикета не появилось требование 3.1?

https://github.com/aabc/ipt-netflow/issues/10 Или Вы в итоге отказались от llist?

[aabc]

AABC, а разве в результате этого тикета не появилось требование 3.1?

https://github.com/aabc/ipt-netflow/issues/10 Или Вы в итоге отказались от llist?

 

Не появилось. Если нет llist, то работает без него. В общем толку от llist мало, но приятно если есть.

[Dark_Angel]

В ядре 3.6 как минимум выпилен Route Cache.

 

Ну между 2.6.27 и 3.6 там вообще кучу всего переделали. Другой вопрос, что на скоростях до 10Гбит включительно, 2.6.27 показывает себя не хуже чем новое ядро. Там, наверное, есть разница в несколько процентов, может даже в 10%, в производительности, но вот существенной, чтобы прямо сейчас всё менять, я не заметил.

 

Я не к тому, что новые ядра пробовать не надо, но все же не в продакшене.

 

А расскажите в двух словах, что не так было с Route Cache? И как его отсутствие влияет на производительность. Я ж так понимаю, что его чем-то заменили?

[s.lobanov]

А расскажите в двух словах, что не так было с Route Cache?

уязвимость к dos-атакам на этот самый кеш

[enots]

Ну между 2.6.27 и 3.6 там вообще кучу всего переделали. Другой вопрос, что на скоростях до 10Гбит включительно, 2.6.27 показывает себя не хуже чем новое ядро. Там, наверное, есть разница в несколько процентов, может даже в 10%, в производительности, но вот существенной, чтобы прямо сейчас всё менять, я не заметил.

 

Вот пример разницы между 2.6.37 и 3.14.23, трафик тот-же.

[Dark_Angel]

уязвимость к dos-атакам на этот самый кеш

 

А где можно про это почитать? Не про саму проблему, а про проблему и решение в 3.6+.

 

Вот пример разницы между 2.6.37 и 3.14.23, трафик тот-же.

 

У меня бывали и не такие ситуации на ядрах после 2.6.32. Там после 2.6.27 начали сильно пилить сетевой стек и далеко не все версии ядра были удачными для разных задач. То есть на одном роутере всё нормально, на второй ставишь и процессор в полку. Более менее всё нормально, по-моему, стало после 3.2.23.

 

То о чем я говорил, это то что если машина на текущем ядре, отрабатывает по примерно заданным параметрам ( а у ТС всё именно так ), то замена ядра существенных улучшений не внесет, а проблем может прибавить.

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

[NiTr0]

А есть какие-то тесты?

Тут тестировали, да и элементаниые тесты типа aida64 memory...

 

Потому что на сколько я помню, АМД первые начали ставить контроллер памяти на кристал с процессором, что как раз нивелировало эту проблему.

Тем не менее, у интела латентность кешей/памяти существенно (чуть ли не в разы) меньше, чем у амд. Речь ессно идет не о LGA775/771.

[s.lobanov]

А где можно про это почитать? Не про саму проблему, а про проблему и решение в 3.6+.

 

http://vger.kernel.org/~davem/columbia2012.pdf

[Igor Diakonov]

Выяснили, что /8 пока решает.

 \         iface                   Rx                   Tx                Total
 ==============================================================================
            eth0:           4.06 Gb/s            2.61 Gb/s            6.67 Gb/s
            eth3:           2.61 Gb/s            4.05 Gb/s            6.65 Gb/s
              lo:           0.00  b/s            0.00  b/s            0.00  b/s
 ------------------------------------------------------------------------------
           total:           6.66 Gb/s            6.66 Gb/s           13.33 Gb/s

root@nat-10g-3:~# sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 1261145

root@nat-10g-3:~# cat /sys/module/nf_conntrack/parameters/hashsize
33554432

perf top
...
 3.87%  [kernel]                     [k] ____nf_conntrack_find
...

 

Performance counter stats for 'sleep 10':

      193,225,295 cache-misses              #   21.330 % of all cache refs     [100.00%]
      905,904,109 cache-references

     10.022140899 seconds time elapsed

 

Трафа, конечно сейчас маловато, в ЧНН посмотрю ещё.

 

Возможно, попробуем уменьшить hashsize до каких-то более реальных значений.

[Igor Diakonov]

А где можно про это почитать? Не про саму проблему, а про проблему и решение в 3.6+.

 

http://vger.kernel.org/~davem/columbia2012.pdf

http://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux.html

https://home.regit.org/2013/03/david-miller-routing-cache-is-dead-now-what/

http://permalink.gmane.org/gmane.linux.network/237956

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89aef8921bfbac22f00e04f8450f6e447db13e42

[Dark_Angel]

Крутые ссылки, парни, спасибо.

 

2NiTr0: тогда понятно почему сервера на АМД стоят дороже, на них спрос меньше. А десктопные версии процессоров от АМД тоже с этой проблемой?

 

Где-то видел обсуждение о роутере на AMD Phenom X6 1090T. 6 ядер, хорошая частота, набортный контроллер памяти. Обсуждение правда было скучное, без цифр. Никто не пробовал?

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

[NiTr0]

А десктопные версии процессоров от АМД тоже с этой проблемой?

А какая разница? Ядра те же...

 

Где-то видел обсуждение о роутере на AMD Phenom X6 1090T. 6 ядер, хорошая частота, набортный контроллер памяти. Обсуждение правда было скучное, без цифр. Никто не пробовал?

Есть такой в хозяйстве. Нагрузка правда смешная на него - менее гига фд. Жрет столько же, сколько 2 рядом стоящих фенома (2- и 4-ядерные) + пара коммутаторов.

[Dark_Angel]

Есть такой в хозяйстве. Нагрузка правда смешная на него - менее гига фд. Жрет столько же, сколько 2 рядом стоящих фенома (2- и 4-ядерные) + пара коммутаторов.

 

Ну и как он по ощущениям, 10Г через него прокачать можно будет? Пока момент с питанием отбросим.

[NiTr0]

Да я откуда знаю :) При нагрузке в несколько % сложно сказать. Опять же - нагрука зависит от ппс сильно нелинейно...

[junjunk2]

Вечер добрый всем.

Не получалось просматривать тему, пока был на Cisco Connect, сейчас вернулся и узнал много нового.

aabc

Спасибо огромное за разяснения, вот результаты в текущий момент. Трафик, правда, уже снизился, но закономерность есть:

[root@nat ~]# cat /sys/module/nf_conntrack/parameters/hashsize
393216
[root@nat ~]# sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 778047
[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

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

Performance counter stats for 'sleep 10':

      145,161,657 cache-misses              #   19.446 % of all cache refs     [100.00%]
      746,486,240 cache-references

     10.001026016 seconds time elapsed

[root@nat ~]# echo 524288 > /sys/module/nf_conntrack/parameters/hashsize
[root@nat ~]# perf stat -a -e cache-misses,cache-references sleep 10

Performance counter stats for 'sleep 10':

      131,758,024 cache-misses              #   17.758 % of all cache refs     [100.00%]
      741,965,282 cache-references

     10.000908255 seconds time elapsed

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

Performance counter stats for 'sleep 10':

      139,902,142 cache-misses              #   18.100 % of all cache refs     [100.00%]
      772,932,741 cache-references

     10.000812280 seconds time elapsed

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

Performance counter stats for 'sleep 10':

      147,243,329 cache-misses              #   19.577 % of all cache refs     [100.00%]
      752,135,431 cache-references

     10.000861747 seconds time elapsed

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

Performance counter stats for 'sleep 10':

      140,169,716 cache-misses              #   17.929 % of all cache refs     [100.00%]
      781,824,160 cache-references

     10.000923943 seconds time elapsed

[root@nat ~]# echo 1572864 > /sys/module/nf_conntrack/parameters/hashsize
[root@nat ~]# perf stat -a -e cache-misses,cache-references sleep 10

Performance counter stats for 'sleep 10':

      128,126,753 cache-misses              #   15.589 % of all cache refs     [100.00%]
      821,919,301 cache-references

     10.001066369 seconds time elapsed

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

Performance counter stats for 'sleep 10':

      108,839,869 cache-misses              #   13.491 % of all cache refs     [100.00%]
      806,755,645 cache-references

     10.000853084 seconds time elapsed

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

Performance counter stats for 'sleep 10':

      117,148,595 cache-misses              #   14.009 % of all cache refs     [100.00%]
      836,241,433 cache-references

     10.000844168 seconds time elapsed

[root@nat ~]#

 

в ссылке по поводу rx_no_dma_resources и tx_restart_queue - там указывается, что увеличивается latency и появляются rx_missed_errors. у меня же ошибок нет, да и latency в ЧНН вполне нормальная, если и отличается от средней нагрузки, то крайне незначительно. Из объяснения, rx_no_dma_res означает, что нет свободного участка dma памяти, чтобы залить RING, если я правильно понял. Но у меня RING - 2048, неужели нет 2кб линейно доступной памяти?? Как-то неясно. Ну и про tx_restart_queue - единственное, что нашел, это вроде как очередь на запись переформировывается до заполнения, ввиду уже отправленных данных. И типа как решение - уменьшение TX_RING. Но тогда выходит это вообще чисто информационный счетик о том, что можно уменьшит latency на выходе?

 

enots

А чем занимается машинка и на каком трафике и pps?

 

Dark_Angel

Подскажите, InterruptThrottleRate=x1,x2,x3,x4 - х1-х4 - это количество прерываний на очередь или на порт? Просто не совсем ясно из документации, да и из обсуждения на форуме. Просто у меня сейчас адаптивный режим, минимальный уровень прерываний - 32-34 тыс. Чтобы при фиксировании получить примерно тот же уровень, надо поставить по 8000 в каждый параметр, или как раз по 32000 в каждый? И еще - может залочить на 40000 прерываний, для уменьшения latency, запаса по производительности вроде бы хватает.

[aabc]

junjunk2

Спасибо за тест! Как я и предполагал, при увеличении hashsize уменьшается % cache-miss/refs.

 

Но у меня RING - 2048, неужели нет 2кб линейно доступной памяти??

Размер ring, это количество дескрипторов (максимум пакетов в очереди), а не памяти.

 

For multiple network ports, ITR must be set for each port (with comma separated values): InterruptThrottleRate=1,1,1,1

[junjunk2]

junjunk2

Спасибо за тест! Как я и предполагал, при увеличении hashsize уменьшается % cache-miss/refs.

 

Тут еще надо учитывать, что собственно сессий было мало. Видимо всё-таки есть какое-то граничное значение, когда cache-miss будет увеличиваться и работа слегка замедляться.

 

Размер ring, это количество дескрипторов (максимум пакетов в очереди), а не памяти.

при среднем размере пакета ( по мировой статистике) ~700 bytes, получаем очередь размером в 1.5 мбайта. учитывая, что slabtop заявляет:

Active / Total Size (% used) : 734105.04K / 1059070.73K (69.3%)

 

Вопрос остается открытым - неужели из 300 мбайт свободной памяти ядра нет последовательных 2МБ?? Откуда ж тогда такая дикая фрагментация? Или я что-то упустил опять?

 

For multiple network ports, ITR must be set for each port (with comma separated values): InterruptThrottleRate=1,1,1,1

 

Тогда в моем случае на двухпортовую сетевушку надо будет сдеать InterruptThrottleRate=32000,32000

[junjunk2]

В ядре 3.6 как минимум выпилен Route Cache.

Dark_Angel, хочу провести тест без Route Cache. Правда не могу нигде найти информации о том, был ли backport этого дела в официальное ядро RHEL 6.6

Если иначе не получится - придется перейти на ELRepo 3.10.x-LT . Ввиду того, что тазик всё-равно перегружать в ближайшее время для изменения intel_idle, возможно подкину и новое ядро. Может кто-нибудь еще что-то подскажет, что конкретно изменилось в сетевой части? А то в основном информация из серии - просто стало лучше. А за счет чего - не понятно совершенно.

[aabc]

Вопрос остается открытым - неужели из 300 мбайт свободной памяти ядра нет последовательных 2МБ?? Откуда ж тогда такая дикая фрагментация? Или я что-то упустил опять?

 

Может не хватить и одного байта если буфер забит (очередь забита), а dma буфер фиксированного размера. Всё это будет зависеть от имплементации конкретного драйвера, полагаю.

 

хочу провести тест без Route Cache. Правда не могу нигде найти информации о том, был ли backport этого дела в официальное ядро RHEL 6.6

 

Ради интереса посмотрел на последнем ядре centos6.6.

 

Судя по главному коммиту где отрубают routing cache, там удаляется функция rt_garbage_collect.

 

root@х:~# cat /etc/redhat-release
CentOS release 6.6 (Final)
root@х:~# uname -r
2.6.32-504.1.3.el6.x86_64
root@х:~# grep rt_garbage /proc/kallsyms
ffffffff814901b0 t rt_garbage_collect
ffffffff81490200 t __do_rt_garbage_collect
ffffffff814905f0 t __rt_garbage_collect

 

Для сравнения ядро 3.14:

root@у:~# uname -r
3.14.23
root@у:~# grep rt_garbage /proc/kallsyms
root@у:~# 

 

Что вообще меняли в ядрах можно читать тут http://kernelnewbies.org/LinuxVersions

[NiTr0]

Из объяснения, rx_no_dma_res означает, что нет свободного участка dma памяти, чтобы залить RING, если я правильно понял. Но у меня RING - 2048, неужели нет 2кб линейно доступной памяти??

А что, элемент буфера равен 1 байту? :) И что, пакеты при получении их сетевухой не пушатся по DMA в память до вызова прерывания (а судя по инфе из интернетов, 1 пакет у интела = 2 кб, а вполне возможно - реально и 4 кб = 1 страница памяти)?

 

Попробуйте покрутить lowmem_reserve_ratio ради эксперимента в сторону уменьшения 1 и 2 параметра.

[junjunk2]

NiTr0

lowmem_reserve_ratio покручу,спасибо.

 

а по поводу tx_queue_restart - у кого какие мысли будут?

[aabc]

junjunk2

tx_restart_queue значит, что передача была восстановлена, после того как она была приостановлена, что в свою очередь происходит, например (и как правило), когда кончились дескрипторы в tx ring. Как на это повлиять - может быть не тривиальной задачей. Вот тут интеловец советует уменьшить tx ring до 256: http://comments.gmane.org/gmane.linux.drivers.e1000.devel/5451 (хотя интуитивно кажется, что надо увеличивать, дальше он советует делать 512), поиграть с coalesce (правда он почему-то пишет в примере про rx, а не tx, ну ему лучше знать) и InterruptThrottleRate.

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

[junjunk2]

aabc

Именно эту ветку и я читал. Думал, может еще у кого был опыт по решению этих проблем.

Буду пробовать. coalesce он предлагает увеличивать для того, чтобы чаще были прерывания на tx. то есть если установлено 100 тыс прерываний на порт, то из них на tx будет 50 тыс.

[aabc]

Coalesce он предлагает увеличивать для того, чтобы чаще были прерывания на tx. то есть если установлено 100 тыс прерываний на порт, то из них на tx будет 50 тыс.

Я про то что в coalesce есть отдельные параметры для tx, но он советует менять rx. Вероятно, это зависит от конкретного драйвера, т.е. в e1000, возможно, каждое второе идет на tx.

[Dark_Angel]

aabc

Именно эту ветку и я читал. Думал, может еще у кого был опыт по решению этих проблем.

Буду пробовать. coalesce он предлагает увеличивать для того, чтобы чаще были прерывания на tx. то есть если установлено 100 тыс прерываний на порт, то из них на tx будет 50 тыс.

 

Так а что у вас за проблема которую вы пытаетесь решить?