Вот наша установка сервера DELL с двумя портами LAN 10G и нашим старым ядром 4.13.4, обслуживающим статический видеоконтент с использованием nginx (~ 8000 активных подключений) с пропускной способностью около 15,5 ГБ (1,2 млн пакетов в секунду) в пике. Мы используем ядро Ubuntu с низкой задержкой, построенное из http://kernel.ubuntu.com/~kernel-ppa/mainline/ без каких-либо изменений в конфигурации по умолчанию (для простоты этой проблемы), которая поставляется с патчами debian / ubuntu.
Итак, мы взяли новое ядро версии 4.18.8 и построили его так же, как и в прошлом году с 4.13.x, но это был большой провал. Производительность связывания была действительно низкой, сеть не пропускала 10,5 Гбит / с на пике, не будучи загруженной больше, чем со старым ядром 4.13.4 - мы собираем системную и сетевую статистику каждые 10 секунд, а загрузка и ввод-вывод почти равны то же самое - никаких проблем с вводом-выводом дисков, которые представляют собой пару SSD. Мы пытались отследить проблему - мы пробовали 4.14.x (4.14.10 до активации Spectre и meltdown), 4.17.x и 4.18.x с активированными Spectre и meltdown и без них (те, которые мы могли отключить). В основном у нас есть лучшая производительность с почти ~ 10% у 4.17.x и 4.18.x без Spectre и Meltdown (те, которые мы могли отключить) и почти такая же скорость с 4.14.10 (все еще не то же самое с 4.13). Мы использовали следующую строку, чтобы отключить все, что можно, от Spectre и Meltdown:
nospectre_v1 nospectre_v2 nospec_store_bypass_disable ssbd=force-off kvm-intel.vmentry_l1d_flush=never l1tf=off nopti no_rfi_flush kpti=off noibrs noibpb nospec no_stf_barrier
Но Spectre_v1 и l1tf нельзя отключить, даже для этого есть варианты. С приведенной выше строкой сеть ядра 4.14.70 на 20% лучше (чем без него, но все же намного хуже, чем должна быть), но с ядром 4.18.12 (и 4.18.8) почти такая же низкая производительность.
Во время тестирования всех ядер мы не меняли никаких других параметров на нашем сервере, и у нас есть система автоматизации, которая проверяет различия, поэтому мы уверены, что все настраиваемые параметры, которые мы изменяем (в системе), применяются во время загрузки. Наша конфигурация склеивания:
bond-mode 4
bond-miimon 100
bond-lacp-rate slow
bond-slaves eth4 eth5
bond-xmit_hash_policy layer3+4
bond-downdelay 200
bond-updelay 200
Кто-нибудь испытывает такое поведение и как мы можем продолжить отладку? Это призрак и деградация производительности расплавления (на самом деле -50% ??)? Может ли это быть из-за изменения параметра по умолчанию в ядрах после 4.13 (хотя мы проверили разницу в конфигурации по умолчанию и между 4.14 и 4.13, и там не так много изменений, и мы попробовали их). Мы также попробовали ядро 4.14.10 - непосредственно перед активацией кода Spectre и meltdown (на самом деле, вероятно, код находится в ядре), и все же мы не смогли достичь производительности ядра 4.13.x, хотя нам удалось заархивировать почти 90% Это. Мы сделали svg с FlameGraph для записи perf:
perf record -F 99 -ag -- sleep 60
И ядра с 4.13.4 по 4.18.12 действительно различаются по тому, сколько времени ядра функционируют, связанные с сетевым стеком. При том же трафике и нагрузке на сервер время, затрачиваемое ядром на функции, связанные с сетевым стеком, в 4.13.4 значительно ниже, чем в 4.18.12, и это похоже на постепенное ухудшение характеристик ядра по сравнению со старыми версиями ядра.