Проблема между интенсивными операциями ввода-вывода и прослушиванием сетевых приложений данных UDP и SCTP - PullRequest
Новая
       4

Проблема между интенсивными операциями ввода-вывода и прослушиванием сетевых приложений данных UDP и SCTP

0 голосов
/ 24 июня 2010

У нас есть приложение, которое использует два типа сокетов: сокет прослушивания UDP и активный сокет SCTP.

В определенное время у нас на одном компьютере выполняются сценарии с высокой активностью ввода-вывода (например, "dd, tar, ..."), в большинстве случаев при запуске этих тяжелых приложений ввода-вывода возникают следующие проблемы. :

  • UDP-сокет закрывается
  • Сокет SCTP все еще активен, и мы можем видеть его в / proc / net / sctp / assocs, однако трафик больше не поступает из этого сокета (пока мы не перезапустим приложение)

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

Приложение работает на сервере с 64-битным 4-х ядерным процессором и ОС RHEL 

# uname -a
Linux server1 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Ответы [ 3 ]

1 голос
/ 27 июня 2010

Когда вы говорите, что UDP-сокет закрывается, что именно вы имеете в виду? Вы пытаетесь send, и это терпит неудачу?

Для SCTP: можете ли вы собирать трассировки wireshark или pcap во время выполнения этих операций ввода-вывода (предпочтительно запускать wireshark на одноранговом узле)? Я предполагаю (обоснованное предположение, не глядя на код), когда эти операции ввода / вывода входят в картину, ваш процесс истощается за время процессора. Другой конец отправляет SCTP Heartbeat messages, на который он не получает ответов. Или, если данные передаются, одноранговый конец не получает SACKS, поскольку они еще не были обработаны стеком SCTP на вашем конце.

Пир, следовательно, прерывает ассоциацию внутри и прекращает отправку вам данных (так как он видит все пути, так как down ergo не отправляет ABORT. В таком случае ваш стек SCTP все еще будет думать, что Ассоциация жива). Попытайтесь подтвердить, каковы значения для Heartbeat timeout, RTO timeout,SACK timeout, maximum Path retransmission & max Association retransmission на одноранговом конце. Я не работал с Kernel SCTP, но sysctl должен быть в состоянии дать вам эти значения.

В любом случае, сбор следов pcap, когда вы наблюдаете эту проблему, даст нам намного лучшее понимание того, что происходит не так. Надеюсь, это поможет.

0 голосов
/ 27 июня 2010

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

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

0 голосов
/ 27 июня 2010

Вот некоторые вещи, которые я бы изучил:

Что загружается в сокет UDP, когда сценарии не запущены? Это непрерывный или взрывной? Сокет когда-либо самопроизвольно закрывается, когда сценарии не работают? Что происходит с данными, считываемыми из сокета? Сколько данных, сгенерированных из сокета (необработанных или обработанных), записывается на диск? Можете ли вы отслеживать загрузку ЦП, сети и дискового ввода-вывода, чтобы увидеть, насыщает ли какой-либо из них? Могут ли сценарии, выполняющие операции ввода-вывода, выполняться с более низким приоритетом или, наоборот, может ли процесс, выполняющий сокет UDP, выполняться с более высоким приоритетом?

...