После обновления FreeBSD на одном из узлов с 13.X на 14.X столкнулся с внезапным увеличением времени выполнения резервного копирования на столько, что задания перестали успевать выполниться за день, что блокировало выполнение уже новых заданий.
Данный узел географически вынесен на другую площадку, и для обеспечения его сетевой доступности используются IPSec туннели через публичные каналы, и, что вполне естественно, на этих каналах присутствуют потери пакетов. Поиск в сети выдавал рекомендации по изменению различный параметров TCP, таких как:
net.inet.tcp.abc_l_var=44
net.inet.tcp.minmss=536
net.inet.tcp.mssdflt=1220
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=16384
Также попались рекомендации по настройке H-TCP и BBR, которые, судя по описанию, должны подходить для разнесённых сетей с большим временем ответа и потярями.
Но, к сожалению, применение всех этих рекомендаций ничего не дало. При этом было обнаружено, что проблемы со скоростью передачи данных наблюдаются только в jail контейнере, который получает доступ в сеть через bridge, построенный на хост системе.
Т.е. при запуска с основной системы iperf3 показывал вполне разумные значения скорости передачи данных для 100Mbit/s канала:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.01 sec 163 MBytes 45.6 Mbits/sec 366 sender
[ 5] 0.00-30.00 sec 162 MBytes 45.3 Mbits/sec receiver
[ 7] 0.00-30.01 sec 167 MBytes 46.8 Mbits/sec 371 sender
[ 7] 0.00-30.00 sec 166 MBytes 46.5 Mbits/sec receiver
[SUM] 0.00-30.01 sec 330 MBytes 92.4 Mbits/sec 737 sender
[SUM] 0.00-30.00 sec 328 MBytes 91.8 Mbits/sec receiver
А из контейнера эта скорость была почти на 2 порядка хуже:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.01 sec 3.50 MBytes 978 Kbits/sec 614 sender
[ 5] 0.00-30.00 sec 2.50 MBytes 699 Kbits/sec receiver
[ 7] 0.00-30.01 sec 3.50 MBytes 978 Kbits/sec 589 sender
[ 7] 0.00-30.00 sec 2.50 MBytes 699 Kbits/sec receiver
[SUM] 0.00-30.01 sec 7.00 MBytes 1.96 Mbits/sec 1203 sender
[SUM] 0.00-30.00 sec 5.00 MBytes 1.40 Mbits/sec receiver
Немного изменив поисковый запрос находим статью на форуме FreeBSD, автор которой также столкнулся с деградацией сетевой производительности после обновления до FreeBSD 14.X, и смог решить данную проблему отключив LRO.
Large Receive Offload (LRO) — это способ увеличения входящей пропускной способности сетевого интерфейса за счёт снижения нагрузки на центральный процессор (C) wikipedia
Т.е. вроде бы разработчики сетевых адаптеров пытаются облегчить жизнь центральному процессору, разработчики FreeBSD пытаются оправдать ожидания предыдущих и включают поддержку этого функционала, а, оказывается, это может быть вредно.
Более того, согласно статье о настройке 10Gb сетевых интерфейсов на официальной wiki FreeBSD, и, в случае, если Ваша система не является конечным узлом и может пересылать TCP данные другим узлам, т.е. является маршрутизатором или мостом (bridge) для других виртуальных машин или контейнеров, рекомендуется отключать не только LRO, но и TCP segmentation offload:
-tso4 -tso6 -lro -vlanhwtso
А что же linux? Почему его пользователи не сталкиваются с этой проблемой? Проверим на нескольких системах параметры сетевого интерфейса:
# ethtool -k enp216s0f0 | grep large-receive-offload
large-receive-offload: off
Потому и не сталкиваются, что по умолчанию LRO выключен. Правда, возможно, у меня просто мало linux на bare metal, и, возможно, в каких-то дистрибутивах LRO включён по умолчанию.
Чей подход в данном случае более правильный вопрос сложный, но то, что на диагностику данной проблемы было убито несколько человекочасов - факт.
