tartila Posted October 25, 2012 Posted October 25, 2012 Господа, кто может подсказать, что я не так понимаю. Имеем сервер шейпирования на базе 2-х четырехядерных ксеонов (8 процов), в который натыканы карты 82576 4-х портовые (2шт), суммарно 8 портов по 1GBit/s. Организован шейпинг бридж - два порта, ну например, port1->port2, port3->port4 (udev переименовал eth->port :) ). Так вот стояла у меня RHEL6 с родным ядром 2.6.32-71.el6.x86_64 и аффинити очередей TxRx просто по ядрам (использовался родной модуль igb от ядра). Балансировка происходила так красиво, что и проца мало потреблялось и все 8 ядер были загружены равномерно. Но был один неприятный баг - система могла рандомно зависнуть. Решил погулять по ядрам вверх и дошел вплоть до 2.6.32-279.el6.x86_64. Но, как оказалось, теперь такой простой подход в smp_affinity, как был ранее - не подходит - система, там где раньше потреблялось до 20% стала потреблять до 70% при том же трафике. Забил на родные ядра, собрал свое ядро с kernel.org - 3.4.11 и скачал отдельно модуль igb с intel.com версии 3.4.8. Начал с ним возится, понял, в чем теперь ньюанс. Теперь очереди TxRx как не прибивай к ядрам -толку от этого не будет. А вот если разбить очереди отдельно на Tx и Rx и прибить, скажем Tx port1 на Rx port2 на одно ядро - то, результат будет аналогичный тому, что было в 2.6.32-71.el6.x86_64 с TxRx очередями. Но вот беда бедовая - все это справедливо только для RSS=1. Одной очереди, как мне видится, маловато. Хотя по сути дела, загружены сейчас все 8 ядер сервера при RSS=1 - портов 8, очередей по 1 на tx и на rx. Как только прибавляю RSS скажем до 2, то могут возникать спонтанные выбросы по нагрузке на произвольное ядро, т.к. очереди распределяются равномерно по ядрам. Вот и вопрос - стоит ли городить отдельно очереди больше 1? Если стоит, то как лучше размазать очереди? Вставить ник Quote
nuclearcat Posted October 25, 2012 Posted October 25, 2012 Сообразно архитектуре процессора. Т.е. не нагружать HT виртуальные ядра, учитывать архитектуру кеша и то, что обмен траффиком между процессорами тоже стоит ресурсов. Вставить ник Quote
tartila Posted October 25, 2012 Author Posted October 25, 2012 (edited) Сообразно архитектуре процессора. Т.е. не нагружать HT виртуальные ядра, учитывать архитектуру кеша и то, что обмен траффиком между процессорами тоже стоит ресурсов. HyperThreading отсутствует как класс в этих Xeon`ах E5450 (и слава Богу). Пытаюсь провести аранжировку аффинити по ядрам с учетом парности ядер (0-1, 2-3) с общим кэшем - результат - только ухудшение. Самый лучший результат пока (просьба не смеяться, что очереди вешаю на одно ядро) при RSS=2 (выше завтра попробую): === port1 tx-0: cpu 7 port3 tx-0: cpu 6 port2 rx-0: cpu 7 port4 rx-0: cpu 6 port1 rx-0: cpu 5 port3 rx-0: cpu 4 port2 tx-0: cpu 5 port4 tx-0: cpu 4 port5 tx-0: cpu 3 port7 tx-0: cpu 2 port6 rx-0: cpu 3 port8 rx-0: cpu 2 port5 rx-0: cpu 1 port7 rx-0: cpu 0 port6 tx-0: cpu 1 port8 tx-0: cpu 0 port1 tx-1: cpu 7 port3 tx-1: cpu 6 port2 rx-1: cpu 7 port4 rx-1: cpu 6 port1 rx-1: cpu 5 port3 rx-1: cpu 4 port2 tx-1: cpu 5 port4 tx-1: cpu 4 port5 tx-1: cpu 3 port7 tx-1: cpu 2 port6 rx-1: cpu 3 port8 rx-1: cpu 2 port5 rx-1: cpu 1 port7 rx-1: cpu 0 port6 tx-1: cpu 1 port8 tx-1: cpu 0 === Edited October 25, 2012 by tartila Вставить ник Quote
nuclearcat Posted October 25, 2012 Posted October 25, 2012 Убедитесь точно, в отношении кеша, а то бывает 0-2 к примеру 1-3 и т.п. например см. /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list Вставить ник Quote
tartila Posted October 26, 2012 Author Posted October 26, 2012 (edited) Убедитесь точно, в отношении кеша, а то бывает 0-2 к примеру 1-3 и т.п. например см. /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list # cat /sys/devices/system/cpu/cpu0/cache/index0/shared_cpu_list 0 # cat /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list 0,4 Что такое index? Edited October 26, 2012 by tartila Вставить ник Quote
alex_001 Posted October 26, 2012 Posted October 26, 2012 Уровень кэша - L1,L2,L3. Нетрудно догадаться по size. кстати , igb всеже по default не очень разумно распределяет прерывания - у меня на машине с 2мя процами по 8 ядер (и 8 очередей на eth) он 4 засунул на 1 физический проц , 4 на другой. Вставить ник Quote
NiTr0 Posted October 26, 2012 Posted October 26, 2012 igb всеже по default не очень разумно распределяет прерывания А он их и не распределяет... Вставить ник Quote
tartila Posted October 26, 2012 Author Posted October 26, 2012 Уровень кэша - L1,L2,L3. Нетрудно догадаться по size. Хорошо, спрошу по другому. :) Если два ядра имеют общий L3 кэш, имеет ли смысл объединять на них прерывания? (ссори, не разбираюсь в сортах кэша) Вставить ник Quote
alex_001 Posted October 26, 2012 Posted October 26, 2012 igb всеже по default не очень разумно распределяет прерывания А он их и не распределяет... А можно поподробнее про механизм? Проинитили девайс , посоздавали очереди.. В какой момент и какой подсистемой ядра они привязываются к IRQ? Вставить ник Quote
tartila Posted October 26, 2012 Author Posted October 26, 2012 igb всеже по default не очень разумно распределяет прерывания А он их и не распределяет... А можно поподробнее про механизм? Проинитили девайс , посоздавали очереди.. В какой момент и какой подсистемой ядра они привязываются к IRQ? google:smp affinity Вставить ник Quote
alex_001 Posted October 26, 2012 Posted October 26, 2012 Уровень кэша - L1,L2,L3. Нетрудно догадаться по size. Хорошо, спрошу по другому. :) Если два ядра имеют общий L3 кэш, имеет ли смысл объединять на них прерывания? (ссори, не разбираюсь в сортах кэша) Если я наконец правильно понял вопрос - стоит ли при наличии очередей > ядер чтото с этим делать IMHO нет. Сократить к-во очередей до к-ва ядер. Самый лучший вариант - 1ядро 1 прерывание. В случае с RSS в эту очередь (на это ядро и соответственно в L1 cache , причем если врублен DCA то сразу в кэш) будут поступать пакеты с 1 flow (расчитывается как хэш финкция от src_ip,dst_ip,src_port_dst_port % [количество-очередей] - если интересно формула есть в интеловском даташите. Соответственно , все данные потока будут находиться в наиболее быстрой (и "близкой")памяти (обрабатываться 1 ядром) , что увеличивает производительность. На 10G сетевых (82599 например) также можно вручную регулировать условия попадания пакетов в определенную очередь (например выделить отдельное ядро для обработки определенных подсетей vlan'ов и.т.д.) Если интересно - искать по запросам типа flow director 5-tuple и.т.д. Эту возможность также можно использовать как аппаратный firewall (пихаем в несуществующую очередь , траф дропается) Насчет кэшей - L1 - непосредственно у каждого ядра , самый быстрый (но и самый маленький). Делится на instruction cache и дата cache (насколько помню для интела) L2,L3 - общий для нескольких ядер , ну и время доступа к ним больше , + возможны блокировки при одновременных попытках доступа по 1 адресу. Посмотреть как отличаются по скорости доступа можно здесь: http://zsmith.co/bandwidth.html - это тест DDR RAM , но хорошо видно когда доступ приходится на кэш , причем и размер хорошо виден. (а заодно и скачать и затестить у себя если интересно) P.S. DCA - Direct Cache Access. Пакеты (заголовки вообщето) прилетающие по MSI-X помещаются сразу в L1 кэш проца. Вставить ник Quote
alex_001 Posted October 26, 2012 Posted October 26, 2012 igb всеже по default не очень разумно распределяет прерывания А он их и не распределяет... А можно поподробнее про механизм? Проинитили девайс , посоздавали очереди.. В какой момент и какой подсистемой ядра они привязываются к IRQ? google:smp affinity Что такое smp_affinity я в курсе - вопрос был в том кем оно задается при инициализации. Гугл в основном показывает ресурсы по теме "как это заюзать" а не "как оно устроено внутри". Понятно , что в исходниках ядра все есть (время на понимание работы таким способом очень уж велико)- но если вдруг есть описание внутренностей - был бы благодарен за ссылку .. И ведь я не зря привел пример с распределением IRQ у меня после загрузки модуля - оно засунуло обработку в разные numa domains , чего например всеми силами стараются не делать process shedulers , у тут такое... Вставить ник Quote
NiTr0 Posted October 26, 2012 Posted October 26, 2012 В какой момент и какой подсистемой ядра они привязываются к IRQ? Ядро ставит affinity на все процессоры (000000ff допустим), на этом роль ядра оканчивается. То, какое ядро будет обслуживать запросы, зависит от выбора планировщика исходя из загруженности ядер. И планировщик не имеет ни малейшего представления о том, что такое несколько очередей прерываний. Свободно ядро, на котором обслуживалось прерывание ранее - прерывание обслуживается ним, занято - перемещается на свободное, выбраное по определенным критериям. Никто не гарантирует, что прерывание будет обслуживаться одним единственным ядром. Далее, affinity отличная от дефолтной ставится уже irqbalance (который тоже скорее всего не догадывается о нескольких очередях) или ручками. Вставить ник Quote
tartila Posted October 26, 2012 Author Posted October 26, 2012 Если я наконец правильно понял вопрос - стоит ли при наличии очередей > ядер чтото с этим делать IMHO нет. Сократить к-во очередей до к-ва ядер. BINGO! Извините меня за мои витиеватые вопросы. :) Теперь еще раз задам обобщающий вопрос, о котором была тема. Вот у меня есть один серв. шейпирования 8 сетевых портов, 8 процов, порты работают в паре, один принимает - другой выплевывает. Ядро 2.6.32-71.el6.x86_64 (RHEL6.0) с набортным igb.ko создает очереди TxRx (оно без params.c), я их раскидываю по принципу очередь на проц - получается 64 очереди (прерывания), можно тот же рандом сделать с помощью irqbalance - результат офигенный - все балансируется, нагрузка равномерная на все ядра с точностью до десятых долей. Ставлю ЛЮБОЕ другое ядро (даже из RHEL 6.1/6.2), сейчас стоит 3.4.11 и что с набортным igb.ko, что собранным с intel.com, сейчас стоит 3.4.8 не получается равномерно наргузить ядра, если делаем TxRx - то система вообще уходит в дремучую загрузку, а если tx/rx с распиновкой типа port1-tx + port2-rx на одном ядре - то вроде неплохо, но есть замечания - о них ниже. Вот сейчас у меня опять же 64 очереди bridge1: port1->port2 bridge2: port3->port4 bridge3: port5->port6 bridge4: port7->port8 port1-tx-0: cpu 7 port3-tx-0: cpu 6 port2-rx-0: cpu 7 port4-rx-0: cpu 6 port1-rx-0: cpu 5 port3-rx-0: cpu 4 port2-tx-0: cpu 5 port4-tx-0: cpu 4 port5-tx-0: cpu 3 port7-tx-0: cpu 2 port6-rx-0: cpu 3 port8-rx-0: cpu 2 port5-rx-0: cpu 1 port7-rx-0: cpu 0 port6-tx-0: cpu 1 port8-tx-0: cpu 0 port1-tx-1: cpu 7 port3-tx-1: cpu 6 port2-rx-1: cpu 7 port4-rx-1: cpu 6 port1-rx-1: cpu 5 port3-rx-1: cpu 4 port2-tx-1: cpu 5 port4-tx-1: cpu 4 port5-tx-1: cpu 3 port7-tx-1: cpu 2 port6-rx-1: cpu 3 port8-rx-1: cpu 2 port5-rx-1: cpu 1 port7-rx-1: cpu 0 port6-tx-1: cpu 1 port8-tx-1: cpu 0 port1-tx-2: cpu 3 port3-tx-2: cpu 2 port2-rx-2: cpu 3 port4-rx-2: cpu 2 port1-rx-2: cpu 1 port3-rx-2: cpu 0 port2-tx-2: cpu 1 port4-tx-2: cpu 0 port5-tx-2: cpu 7 port7-tx-2: cpu 6 port6-rx-2: cpu 7 port8-rx-2: cpu 6 port5-rx-2: cpu 5 port7-rx-2: cpu 4 port6-tx-2: cpu 5 port8-tx-2: cpu 4 port1-tx-3: cpu 3 port3-tx-3: cpu 2 port2-rx-3: cpu 3 port4-rx-3: cpu 2 port1-rx-3: cpu 1 port3-rx-3: cpu 0 port2-tx-3: cpu 1 port4-tx-3: cpu 0 port5-tx-3: cpu 7 port7-tx-3: cpu 6 port6-rx-3: cpu 7 port8-rx-3: cpu 6 port5-rx-3: cpu 5 port7-rx-3: cpu 4 port6-tx-3: cpu 5 port8-tx-3: cpu 4 И нагрузка иногда скачет следующим образом: 20:59:04 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:59:06 all 0,00 0,00 0,11 0,00 0,00 6,04 0,00 0,00 93,85 20:59:06 0 0,00 0,00 0,00 0,00 0,00 5,83 0,00 0,00 94,17 20:59:06 1 0,00 0,00 0,93 0,00 0,00 6,48 0,00 0,00 92,59 20:59:06 2 0,00 0,00 0,00 0,00 0,00 6,45 0,00 0,00 93,55 20:59:06 3 0,00 0,00 0,00 0,00 0,00 8,85 0,00 0,00 91,15 20:59:06 4 0,00 0,00 0,00 0,00 0,00 2,56 0,00 0,00 97,44 20:59:06 5 0,00 0,00 0,00 0,00 0,00 11,88 0,00 0,00 88,12 20:59:06 6 0,00 0,00 0,00 0,00 0,00 2,48 0,00 0,00 97,52 20:59:06 7 0,00 0,00 0,00 0,00 0,00 4,72 0,00 0,00 95,28 20:59:33 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:59:35 all 0,00 0,00 0,00 0,00 0,00 11,94 0,00 0,00 88,06 20:59:35 0 0,00 0,00 0,00 0,00 0,00 13,74 0,00 0,00 86,26 20:59:35 1 0,00 0,00 0,00 0,00 0,00 7,41 0,00 0,00 92,59 20:59:35 2 0,00 0,00 0,00 0,00 0,00 1,68 0,00 0,00 98,32 20:59:35 3 0,00 0,00 0,00 0,00 0,00 17,91 0,00 0,00 82,09 20:59:35 4 0,00 0,00 0,00 0,00 0,00 19,29 0,00 0,00 80,71 20:59:35 5 0,00 0,00 0,00 0,00 0,00 25,20 0,00 0,00 74,80 20:59:35 6 0,00 0,00 0,00 0,00 0,00 4,00 0,00 0,00 96,00 20:59:35 7 0,00 0,00 0,00 0,00 0,00 2,65 0,00 0,00 97,35 20:59:57 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:59:59 all 0,00 0,00 0,11 0,00 0,00 7,81 0,00 0,00 92,09 20:59:59 0 0,00 0,00 0,00 0,00 0,00 10,24 0,00 0,00 89,76 20:59:59 1 0,00 0,00 0,00 0,00 0,00 12,39 0,00 0,00 87,61 20:59:59 2 0,00 0,00 0,00 0,00 0,00 4,92 0,00 0,00 95,08 20:59:59 3 0,00 0,00 0,00 0,00 0,00 6,90 0,00 0,00 93,10 20:59:59 4 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 100,00 20:59:59 5 0,00 0,00 0,00 0,00 0,00 20,66 0,00 0,00 79,34 20:59:59 6 0,00 0,00 0,81 0,00 0,00 3,23 0,00 0,00 95,97 20:59:59 7 0,00 0,00 0,00 0,00 0,00 3,67 0,00 0,00 96,33 Вот какого оно так делает? На 2.6.32-71.el6.x86_64 такого не было :( # cat /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list 0,4 # cat /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list 1,5 # cat /sys/devices/system/cpu/cpu2/cache/index2/shared_cpu_list 2,6 # cat /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_list 3,7 В понедельник позырю 2.6.32-71.el6.x86_64 в /sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list и отключу в 3.4.11 perfomance counters (сейчас включены). Вставить ник Quote
alex_001 Posted October 26, 2012 Posted October 26, 2012 В какой момент и какой подсистемой ядра они привязываются к IRQ? Ядро ставит affinity на все процессоры (000000ff допустим), на этом роль ядра оканчивается. То, какое ядро будет обслуживать запросы, зависит от выбора планировщика исходя из загруженности ядер. И планировщик не имеет ни малейшего представления о том, что такое несколько очередей прерываний. Свободно ядро, на котором обслуживалось прерывание ранее - прерывание обслуживается ним, занято - перемещается на свободное, выбраное по определенным критериям. Никто не гарантирует, что прерывание будет обслуживаться одним единственным ядром. Далее, affinity отличная от дефолтной ставится уже irqbalance (который тоже скорее всего не догадывается о нескольких очередях) или ручками. Дык , в том то и дело что не FF ставит , а привязывает 1 очередь к 1 ядру. У меня при загрузке драйвера расставило как 1,2,4,8 ... e.t.c. 105: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0 106: 938723 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-0 107: 50434 649605 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-1 108: 45912 0 698130 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-2 109: 71729 0 0 653190 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-3 110: 50493 0 0 0 0 0 0 0 611653 0 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-4 111: 70917 0 0 0 0 0 0 0 0 610529 0 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-5 112: 47064 0 0 0 0 0 0 0 0 0 599213 0 0 0 0 0 PCI-MSI-edge eth0-TxRx-6 113: 49503 0 0 0 0 0 0 0 0 0 0 655081 0 0 0 0 PCI-MSI-edge eth0-TxRx-7 xbgp eth-affinity # cat /proc/irq/105/smp_affinity 00000000,000000ff xbgp eth-affinity # cat /proc/irq/106/smp_affinity 00000000,00000001 xbgp eth-affinity # cat /proc/irq/107/smp_affinity 00000000,00000002 xbgp eth-affinity # cat /proc/irq/108/smp_affinity 00000000,00000004 И такая картина _сразу_ после загрузки драйвера (хотя на сам eth0 он всеже FF поставил). Вставить ник Quote
nuclearcat Posted October 26, 2012 Posted October 26, 2012 Кажется там три уровня кеша, и это нужно брать во внимание. Т.е. у ядер 0,4 общий кеш, следовательно одинаковую нагрузку нужно вешать на них. Если port1-tx-0 и port1-rx-0 идет один и тот же поток, их нужно вешать на ядра с общим кешем. Вот это как-то выглядит не совсем хорошо: port1-tx-0: cpu 7 port1-rx-0: cpu 5 Либо стараться развешивать на однин проц RX, на другой TX, либо на одно ядро rx-0, на другое tx-0 (один и тот же поток), нужно экспериментировать. Вставить ник Quote
tartila Posted October 28, 2012 Author Posted October 28, 2012 Кажется там три уровня кеша, и это нужно брать во внимание. Т.е. у ядер 0,4 общий кеш, следовательно одинаковую нагрузку нужно вешать на них. Если port1-tx-0 и port1-rx-0 идет один и тот же поток, их нужно вешать на ядра с общим кешем. Вот это как-то выглядит не совсем хорошо: port1-tx-0: cpu 7 port1-rx-0: cpu 5 Либо стараться развешивать на однин проц RX, на другой TX, либо на одно ядро rx-0, на другое tx-0 (один и тот же поток), нужно экспериментировать. Почему это выглядит плохо? Эти две очереди занимаются разным трафиком. Вот port1-tx-0 и port2-rx-0 занимаются одинаковым трафиком. Вопрос еще вот какой, если траф попадает в port1-rx-0, вылетит ли он в port2-tx-0 или может в port2-tx-1 или port2-tx-2? Вставить ник Quote
alex_001 Posted October 28, 2012 Posted October 28, 2012 Кажется там три уровня кеша, и это нужно брать во внимание. Т.е. у ядер 0,4 общий кеш, следовательно одинаковую нагрузку нужно вешать на них. Если port1-tx-0 и port1-rx-0 идет один и тот же поток, их нужно вешать на ядра с общим кешем. Вот это как-то выглядит не совсем хорошо: port1-tx-0: cpu 7 port1-rx-0: cpu 5 Либо стараться развешивать на однин проц RX, на другой TX, либо на одно ядро rx-0, на другое tx-0 (один и тот же поток), нужно экспериментировать. Почему это выглядит плохо? Эти две очереди занимаются разным трафиком. Вот port1-tx-0 и port2-rx-0 занимаются одинаковым трафиком. Вопрос еще вот какой, если траф попадает в port1-rx-0, вылетит ли он в port2-tx-0 или может в port2-tx-1 или port2-tx-2? Выглядит это плохо по причине того что приходится гонять трафик на другой физический проц (а физически pci-e для eth0 висит на другом) - загружаем QPI линки между процами , (и не совсем понятно что с DCA происходит при этом). Естественно latency при этом явно больше. Плата у меня такая: http://download.intel.com/support/motherboards/server/sb/g34153003_s2600ip_w2600cr_tps_r110.pdf , как там все раскидано - на стр 19 есть весьма понятная картинка. Причем дефолтное поведение ixgbe более разумное - со своего проца не уползает: xbgp ~ # cat /proc/interrupts | grep eth13 262: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-0 263: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-1 264: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-2 265: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-3 266: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-4 267: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-5 268: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-6 269: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-7 270: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-8 271: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-9 272: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-10 273: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-11 274: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-12 275: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-13 276: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-14 277: 0 0 0 0 0 0 0 0 47 0 0 0 0 0 0 0 PCI-MSI-edge eth13-TxRx-15 278: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI-edge eth13 xbgp ~ # cat /proc/irq/262/smp_affinity 00000000,0000ff00 xbgp ~ # cat /proc/irq/263/smp_affinity 00000000,0000ff00 xbgp ~ # cat /proc/irq/264/smp_affinity 00000000,0000ff00 xbgp ~ # cat /proc/irq/278/smp_affinity 00000000,0000ff00 Вставить ник Quote
kayot Posted October 29, 2012 Posted October 29, 2012 BINGO! Извините меня за мои витиеватые вопросы. :) Теперь еще раз задам обобщающий вопрос, о котором была тема. Вот у меня есть один серв. шейпирования 8 сетевых портов, 8 процов ... получается 64 очереди (прерывания) ... А на кой фиг вам при 8 интерфейсах и 8 ядрах вообще очереди и геморрой с балансировкой? Отключите RSS, прибейте жестко ядро-сетевка и живите счастливо, не? Вставить ник Quote
tartila Posted October 30, 2012 Author Posted October 30, 2012 BINGO! Извините меня за мои витиеватые вопросы. :) Теперь еще раз задам обобщающий вопрос, о котором была тема. Вот у меня есть один серв. шейпирования 8 сетевых портов, 8 процов ... получается 64 очереди (прерывания) ... А на кой фиг вам при 8 интерфейсах и 8 ядрах вообще очереди и геморрой с балансировкой? Отключите RSS, прибейте жестко ядро-сетевка и живите счастливо, не? Вопрос в том, что при большом PPS одна очередь может отхавать сразу 100% ядра и тупо повесить всю обработку далее. Вот такая шляпа. InterruptThrottleRate крутил - не помогало. Вставить ник Quote
tartila Posted October 30, 2012 Author Posted October 30, 2012 Выглядит это плохо по причине того что приходится гонять трафик на другой физический проц (а физически pci-e для eth0 висит на другом) - загружаем QPI линки между процами , (и не совсем понятно что с DCA происходит при этом). Естественно latency при этом явно больше. Плохо понимаю, почему трафик должен гонятся между процами? port1-tx-0 отдает траф в ЛВС, port1-rx-0 принимает совершенно другой траф, наоборот из ЛВС. Вставить ник Quote
kayot Posted October 30, 2012 Posted October 30, 2012 BINGO! Извините меня за мои витиеватые вопросы. :) Теперь еще раз задам обобщающий вопрос, о котором была тема. Вот у меня есть один серв. шейпирования 8 сетевых портов, 8 процов ... получается 64 очереди (прерывания) ... А на кой фиг вам при 8 интерфейсах и 8 ядрах вообще очереди и геморрой с балансировкой? Отключите RSS, прибейте жестко ядро-сетевка и живите счастливо, не? Вопрос в том, что при большом PPS одна очередь может отхавать сразу 100% ядра и тупо повесить всю обработку далее. Вот такая шляпа. InterruptThrottleRate крутил - не помогало. Если трафик по интерфейсам распределяется примерно равномерно(а так должно быть), то никаких перекосов не возникнет, а накладные расходы однозначно будут ниже + проще конфигурировать. Вставить ник Quote
tartila Posted October 30, 2012 Author Posted October 30, 2012 Если трафик по интерфейсам распределяется примерно равномерно(а так должно быть), то никаких перекосов не возникнет, а накладные расходы однозначно будут ниже + проще конфигурировать. Трафик распределяется равномерно, но мы живем в реальном мире, где внутри сети может существовать, например botnet. Результат - слабое увеличение bps, но гигантское увеличение pps, которое вызывает бросок нагрузки на очередь, что приводит к деградации задержки и пропускной способности. Уж лучше я потеряю немного при балансировке между ядрами, но распределю нагрузку равномерно, нежели чем провалюсь на одной недогруженной очереди. Intel в документации к igb пишет такую загадочную фразу NOTE: When igb is loaded with default settings and multiple adapters are in use simultaneously, the CPU utilization may increase non- linearly. In order to limit the CPU utilization without impacting the overall throughput, we recommend that you load the driver as follows: modprobe igb InterruptThrottleRate=3000,3000,3000 Вот такое как раз я видел при InterruptThrottleRate=1/3 при высоких pps, когда траф проседал. Вставить ник Quote
tartila Posted December 2, 2012 Author Posted December 2, 2012 Решил поделиться впечатлениями, которые получил в результате наблюдений. Если сделать общее кол-во очередей (на все сетевые карты) равным кол-ву ядер - это не вариант, трафик на такой очереди может увести ядро в 100% из-за мелкого трафика. Если сделать кол-во очередей (на каждую сетевую карту) равным кол-ву ядер, то ситуация становится той, которую я описал в первом посте - на старом ядре 2.6.32-71.el6.x86_64 нагрузка приемлемая, ядро, даже балансирует само при ff в smp_affinity (но ядро не стабильное - машина ребутается самопроизвольно), а на новом ядре 3.4.11-custom уже ff не работает (забивает произвольно под 100% одно ядро - другие бездействуют) и балансировка очередей внутри RSS работает НЕ корректно, сейчас объясню свои наблюдения. И так, протестил два драйвера igb: igb-3.4.8 и igb-4.0.17 - результат одинаковый. Даю в options следующее: options igb RSS=3,3,3,3,3,3,3,3. То есть, ITR и прочее на усмотрение драйвера, очереди не разбиваю на tx/rx (это особо не влияет), всего на каждый порт сетевой создаю по три очереди, две балансирую на одно ядро (2 порта бриджа), а с третьим играюсь. Так вот заметил, что в новых ядрах, которые старше 2.6.32-71.el6.x86_64 и версия драйвера старше 2.1.0-k2 (тестирую на 3.4.11 и 4.0.17 (драйвер)), то трафик не распределяется внутри очередей RSS, а может, например, попасть только в очередь port1-TxRx-2, при этом очереди TxRx-1 и TxRx-0 будут бездействовать. Определяю это так. Например, назначаю (port1-port2 - это bridge): === port1-TxRx-0: cpu 7 port1-TxRx-1: cpu 3 port1-TxRx-2: cpu 7 port2-TxRx-0: cpu 7 port2-TxRx-1: cpu 3 port2-TxRx-2: cpu 7 === Наблюдаю большую нагрузку на CPU7 по mpstat => это очередь либо 0 либо 2. Переношу вторую очередь на другое ядро, например CPU0. === port1-TxRx-0: cpu 7 port1-TxRx-1: cpu 3 port1-TxRx-2: cpu 0 port2-TxRx-0: cpu 7 port2-TxRx-1: cpu 3 port2-TxRx-2: cpu 0 === Получаю эту нагрузку (например, 80%) на CPU0, CPU7 и CPU3 - отдыхают (2-10 %). Почему? Где-то есть ошибки/отличия в алгоритме хэширования в RSS. Есть мысль попробовать собрать вручную 2.1.0-k2 на ядре 3.4.11. :))) (ядра 7 и 3 имеют общий L3 кэш, как уже писалось ранее) Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.