Выносить решили для того, чтоб не аффектить основной трафик. На момент написания 40Г было только между лифами, а между лифами и спайнами были две десятки.
Копать дальше в LACP не стали: покрутили только параметры, о которых я написал в статье и сравнили с ospf. Решили не углубляться дальше и просто использовали то, что показало себя лучше.
Тесты проводили в основном TCP (UDP гоняли пару раз всего). Результаты приведены из qperf — он показывает лэтэнси и bw в зависимости от размера пакета. Он умеет последовательно запускать их разного размера
qperf --time 10 -oo msg_size:1:64K:*2 -v --use_bits_per_sec ${test_address} tcp_lat tcp_bw
В итоге прогонялось по восходящей от 1 байта до 64 KiB
Наименьшее лэтэнси было обычно пакетами до 32 байт
На коммутаторах и интерфейсах bw показывалась одинаковая.
Разница в 10 и 100 потоков — на самом сервере упора в ресурсы не заметили. Прерывания были расбросаны по ядрам и ни одно не упиралось в потолок, памяти было достаточно, ошибок на сетевых интерфейсах или рост очереди не замечали.
Погрешили на коммутаторы.
Поскольку появилось время и возможность потестировать, думаем в ближайшее время разобраться с проблемой у LACP и падением производительности при росте потоков до 100.
Не совсем понял вопроса. Модель и вендора я знал, текущие параметры и максимальные, которые может использовать текущий драйвер — я получил от ethtool (это в статье указано)
На тот момент это были интеловские карты, драйвер ixgbe я менять не стал.
Наверно не syslog а sysctl?
Те, которые net.core.*mem* — есть мнение что следует использовать формулу 1М на каждый 1G оперативной памяти. Мы решили немного подстраховаться, и для начала остановились на 54М при 128G оперативы. Меняя этот параметр под нагрузкой, не заметили по графикам никаких изменений, и решили оставить как есть.
net.core.somaxconn — отталкивались от статистики количества текущих соединений на боевых машинах.
Копать дальше в LACP не стали: покрутили только параметры, о которых я написал в статье и сравнили с ospf. Решили не углубляться дальше и просто использовали то, что показало себя лучше.
Тесты проводили в основном TCP (UDP гоняли пару раз всего). Результаты приведены из qperf — он показывает лэтэнси и bw в зависимости от размера пакета. Он умеет последовательно запускать их разного размера
qperf --time 10 -oo msg_size:1:64K:*2 -v --use_bits_per_sec ${test_address} tcp_lat tcp_bw
В итоге прогонялось по восходящей от 1 байта до 64 KiB
Наименьшее лэтэнси было обычно пакетами до 32 байт
На коммутаторах и интерфейсах bw показывалась одинаковая.
Разница в 10 и 100 потоков — на самом сервере упора в ресурсы не заметили. Прерывания были расбросаны по ядрам и ни одно не упиралось в потолок, памяти было достаточно, ошибок на сетевых интерфейсах или рост очереди не замечали.
Погрешили на коммутаторы.
Поскольку появилось время и возможность потестировать, думаем в ближайшее время разобраться с проблемой у LACP и падением производительности при росте потоков до 100.
Поправил статью, добавил ссылку на первую часть в начало.
Спасибо за совет.
На тот момент это были интеловские карты, драйвер ixgbe я менять не стал.
docs.frrouting.org/en/latest/ospfd.html
Те, которые net.core.*mem* — есть мнение что следует использовать формулу 1М на каждый 1G оперативной памяти. Мы решили немного подстраховаться, и для начала остановились на 54М при 128G оперативы. Меняя этот параметр под нагрузкой, не заметили по графикам никаких изменений, и решили оставить как есть.
net.core.somaxconn — отталкивались от статистики количества текущих соединений на боевых машинах.