потеря многоадресных пакетов - запуск двух экземпляров одного и того же приложения

Question

В Redhat Linux у меня есть многоадресный прослушиватель, который прослушивает очень занятый источник многоадресных данных. Он работает отлично сам по себе, без потерь пакетов. Однако, как только я запустил второй экземпляр того же приложения с точно такими же настройками (тот же IP-адрес src / dst, размер буфера носителей, размер пользовательского буфера и т. Д.), Я начал видеть очень частые потери пакетов в обоих экземплярах. И они потеряли точно такие же пакеты. Если я остановлю один из экземпляров, оставшийся вернется в нормальное состояние без потери пакетов.

Изначально я думал, что это проблема загрузки процессора / ядра, возможно, он не смог вытащить пакеты из буфера достаточно быстро. Итак, я сделал еще один тест. Я все еще держу один экземпляр приложения работающим. Но затем запустили совершенно другого многоадресного прослушивателя на том же компьютере, но использовали вторую карту NIC и прослушивали другой, но даже более загруженный источник многоадресной рассылки. Оба приложения работают нормально без потери пакетов.

Таким образом, похоже, что одна плата NIC недостаточно мощна для поддержки двух многоадресных приложений, даже если они слушают одно и то же. Возможная причина проблемы потери пакетов может заключаться в том, что в этом сценарии драйверу карты NIC необходимо скопировать входящие данные в два буфера носителей, и эта дополнительная задача копирования слишком сложна для обработки карты эфира, поэтому она отбрасывает пакеты. Любой более глубокий анализ этой проблемы и возможных решений?

Спасибо

Answer 1

Вы в основном обнаруживаете, что ядро ​​неэффективно при разветвлении многоадресных пакетов. В худшем случае код предназначен для каждого входящего пакета, выделяющего два новых буфера, объект SKB и полезную нагрузку пакета, и дважды копирует буфер NIC.

Выберите наилучший сценарий, для каждого входящего пакета выделяется новый SKB, но полезная нагрузка пакета распределяется между двумя сокетами с подсчетом ссылок. Теперь представьте, что происходит, когда два приложения, каждое на своем ядре и на отдельных сокетах. Каждая ссылка на полезную нагрузку пакета приводит к остановке шины памяти, в то время как оба основных кэша должны сбрасываться и перезагружаться, и, кроме того, каждому приложению приходится переключать контекст ядра назад и вперед для передачи полезной нагрузки сокета. Результат - ужасная производительность.

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

Примерами являются Rendezvous TIBCO и Ultra Messaging 29 West, показывающие шину IPC 660 нс:

http://www.globenewswire.com/newsroom/news.html?d=194703