Где возможные места задержек очереди/буферизации в многоадресной рассылке Linux?

Пакеты могут ставиться в очередь в ядре отправки и приема, сетевой карте и сетевой инфраструктуре. Вы найдете множество элементов, которые вы можете протестировать и настроить.

Для сетевой карты вы обычно можете найти параметры объединения прерываний - как долго сетевая карта будет ждать, прежде чем уведомить ядро ​​​​или отправить по сети, ожидая пакетной обработки пакетов.

Для Linux у вас есть «буферы» отправки и получения, чем они больше, тем больше вероятность того, что вы столкнетесь с большей задержкой, поскольку пакеты обрабатываются в пакетных операциях.

Для архитектуры и версии Linux вы должны знать, насколько дорогими являются переключения контекста и включены ли блокировки или упреждающее планирование. Подумайте о том, чтобы свести к минимуму количество запущенных приложений, используя сходство процессов для привязки процессов к определенным ядрам.

Не забывайте о времени, версия ядра Linux, которую вы используете, имеет ужасную точность на gettimeofday() часах (2-4 мс) и является довольно дорогим вызовом. Рассмотрите возможность использования альтернатив, таких как чтение из основного TSC или внешнего устройства HPET.

Диаграмма от Intel: http://www.theinquirer.net/IMG/142/96142/latency-580x358.png?1272514422

Это большой вопрос. В CentOS, как и в большинстве разновидностей *nix, есть буфер приема/отправки UDP для каждого многоадресного сокета. Размер этого буфера контролируется sysctl.conf, вы можете просмотреть размер ваших буферов, вызвав /sbin/sysctl -a

Элементы ниже показывают мой размер по умолчанию и максимальный размер приема udp в байтах. Чем больше эти числа, тем больше буферизация и, следовательно, задержка, которую может создать сеть/ядро, если ваше приложение слишком медленно потребляет данные. Если вы создали хорошую устойчивость к потере данных, вы можете сделать эти буферы очень маленькими, и вы не увидите увеличения задержки и восстановления, описанных выше. Компромисс заключается в потере данных при переполнении буфера, что вы, возможно, уже видели.

[~]$ /sbin/sysctl -a | память net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

В большинстве случаев вам нужно установить default = на ваш максимум, если вы не контролируете это при создании своего сокета.

последнее, что вы можете сделать (в зависимости от версии вашего ядра), это просмотреть статистику UDP PID для вашего процесса или, по крайней мере, для всего окна.

кошка /proc/net/snmp | grep -i Udp Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 81658157063 145 616548928 3896986

кошка /proc/PID/net/snmp | grep -i Udp Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 81658157063 145 616548928 3896986

Если из моего поста неясно, задержка связана с тем, что ваше приложение недостаточно быстро потребляет данные и заставляет ядро ​​буферизовать трафик в указанной выше структуре. Сеть, ядро ​​и даже кольцевые буферы вашей сетевой карты могут играть роль в задержке, но все эти элементы обычно добавляют всего несколько миллисекунд.

Дайте мне знать, что вы думаете, и я могу дать вам больше информации о том, где искать в вашем приложении, чтобы повысить производительность.

Если вы решите, что вам нужно перехватывать пакеты в производственной среде, возможно, стоит рассмотреть возможность использования портов монитора на ваших коммутаторах и перехвата пакетов с помощью непроизводственных машин. Это также позволит вам захватывать пакеты в нескольких точках на пути передачи и сравнивать то, что вы видите.