TCP отправляет проблему производительности о 18,04

Я играю вокруг с Ubuntu 18.04, и я замечаю регрессию производительности TCP, которая препятствует тому, чтобы я обновил свои текущие рабочие серверы, так как они очень чувствительны к задержке.

Для моего конкретного примера использования я реализовал простую тестовую программу TCP, которую я выполняю как сервер, ожидая определенного числа клиентов, чтобы быть соединенным прежде, чем отправить пакет сообщений всем клиентам. Я затем измеряю время, оно берет к sendmsg () буфер фиксированного размера клиентам N.

Пример кода

io_uring.c client.c

Я выполняю сервер и клиенты на двух отличных машинах, расположенных в том же центре обработки данных.

Результаты

Ubuntu 16.04

Версия

srv01:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

srv01:~$ uname -ra
Linux srv01 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

sysctl

net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_moderate_rcvbuf = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_rmem = 131072 1048576 16777216
net.ipv4.tcp_wmem = 131072 1048576 16777216

Выполненный

srv01:~$ taskset -c 15,17,19 ./iouring --port 4040 --clients-count 3 --buffer-size 128 --batch-size 100 --sleep-ms 1 --total-messages 500000 --sockopt n
Send latency report
Min: 679ns
Mean: 1048ns
Max: 13949ns
p(0.100000) = 726ns
p(0.200000) = 734ns
p(0.500000) = 750ns
p(0.800000) = 859ns
p(0.900000) = 1338ns
p(0.990000) = 5024ns

Ubuntu 18.04

Версия

srv02:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

srv02:~$ uname -ra
Linux srv02 4.20.17-042017-generic #201903190933 SMP Tue Mar 19 13:36:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

sysctl

net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_moderate_rcvbuf = 0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_rmem = 131072 1048576 16777216
net.ipv4.tcp_wmem = 131072 1048576 16777216

Выполненный

srv02:~$ taskset -c 15,17,19 ./iouring --port 4040 --clients-count 3 --buffer-size 128 --batch-size 100 --sleep-ms 1 --total-messages 500000 --sockopt n
Send latency report
Min: 819ns
Mean: 4660ns
Max: 25061ns
p(0.100000) = 1379ns
p(0.200000) = 2660ns
p(0.500000) = 4871ns
p(0.800000) = 6559ns
p(0.900000) = 7416ns
p(0.990000) = 9444ns

Как Вы видите, существует значительное отбрасывание производительности на Ubuntu 18.04 с ядром 4.20 (я наблюдаю то же самое относительно ядра 4.15 и 4.18). Я использую те же самые машины (те же аппаратные средства).

Так или иначе похоже, что это связано с включаемым TCP_NODELAY или нет. При отключении TCP_NODELAY (нет - sockopt), я добираюсь в 50-й раз 1 005 нс (Ubuntu 18.04).

srv02:~$ taskset -c 15,17,19 ./iouring --port 4040 --clients-count 3 --buffer-size 128 --batch-size 100 --sleep-ms 1 --total-messages 500000
Send latency report
Min: 817ns
Mean: 1790ns
Max: 15374ns
p(0.100000) = 955ns
p(0.200000) = 964ns
p(0.500000) = 1006ns
p(0.800000) = 1601ns
p(0.900000) = 4475ns
p(0.990000) = 9516ns

Тот же тест на RHEL8, ядро 4.18 не показывает различия в производительности с или без TCP_NODELAY (50-х 950 нс).

Какая-либо идея, что могло вызвать это? Я могу предоставить больше подробную информацию в случае необходимости.

Спасибо

6
задан 24 October 2019 в 05:19

1 ответ

Кажется, что Ваши 16,04 ядер не исправляются для призрака/краха.

В моем ядре понимания 4.4.0-109 содержит частичный патч, Вы работаете 4.4.0-97, которые не смягчили действий к обращению к атакам по сторонним каналам, таким образом обеспечив лучшую производительность.

Действительно ли мудро выполнить тех, которые в производственной системе SMP - совершенно другой вопрос...

1
ответ дан 23 November 2019 в 08:11

Другие вопросы по тегам:

Похожие вопросы: