Оптимизация входящего UDP вещания в Linux

Question

Environment

• Linux/RedHat
• 6 ядер
• Java 7/8
• 10G

Применение

• его низкой латентностью высокой частоты торгов применение
• А получает вещание через многоадресной UDP
• Есть несколько потоков данных
• Каждый Входящий размер пакета меньше, чем 1K (фиксированный размер)
• задержка Применение составляет около 4 микросекунды

Архитектура

• Отдельный поток приложения отображается в каждом потоке входящего многоадресного
• получает данные из сокета, используя multicastsocket.receive() в нативном байт
• Б обрабатываются и портфель заказов получают

Проблема

Несмотря на допустимую задержку приложения около 4 микросекунд, мы не можем получить желаемую производительность. Мы считаем, что это из-за латентности сети.

шаги по настройке используется

• Увеличение размера следующих параметров:
• netdev_max_backlog
• NIC кольцевого буфера приема Размер
• rmem_max
• tcp_mem
• socketreceivebuffer (в коде)

Вопрос:

1. Мы заметили, что производительность приложения ухудшились после того, как мы увеличили значение указанных выше параметров. Каковы рекомендуемые параметры для оптимизации & рекомендуемых значений. Требуется руководство по оптимизации входящего вещания?
2. Есть ли способ более точного измерения латентности сети в такой среде.Обратите внимание, что отправитель UDP является внешний объект (обмен)

Заранее спасибо

Answer 1

Это не ясно, что и как вы измеряете.

Вы упомянули, что получаете UDP, почему вы настраиваете размер буфера TCP?

Как правило, увеличение размера буфера входящих сокетов может помочь вам с потерей пакетов на медленном приемнике, но это не уменьшит время ожидания.

Вы можете, как узнать больше о bufferbloat:

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

---

Вы также можете использовать Java для низкой латентностью применения. Обычно люди не могут добиться таких латентностей с помощью Java. Одной из основных причин является сборщик мусора. См Quantifying the Performance of Garbage Collection vs. Explicit Memory Management для более подробной информации:

Сравнения времени выполнения, потребления пространства и виртуальных следов памяти в диапазоне показателей, мы показали, что производительность выполнения из лучших исполняющего сборщика мусора конкурентоспособна с явным управлением памяти при наличии достаточной памяти. В частности, , когда сбор мусора имеет в пять раз больше памяти по мере необходимости, его производительность выполнения соответствует или немного превышает , что явное управление памятью. Однако производительностьмусора в сборе существенно ухудшается, когда он должен использовать кучи меньшего размера . В 3 раза больше памяти, он работает на 17% медленнее на в среднем, и с вдвое большим объемом памяти он работает на 70% медленнее. Garbage коллекция также более восприимчива к поисковой обработке, когда физическое памяти мало. В таких условиях все сборщики мусора , которые мы рассматриваем здесь, подвергаются штрафам с производительностью по порядку величины относительно явного управления памятью.

Люди, делающие HFT с использованием Java, часто полностью отключают сборку мусора и ежедневно перезапускают свои системы.