nginx затирает трафик sftp в часы пик - есть ли ответ на этот вопрос?

Вероятно, это продолжение мой предыдущий (без ответа) вопрос потому что основная причина, вероятно, та же.

У меня есть Linux-сервер с запущенными на нем nginx и sshd. Он находится на общей неизмеренной ссылке со скоростью 100 Мбит / с. В "пиковые времена" (в основном, днем ​​в США) производительность sftp становится очень плохой, иногда время ожидания истекает, прежде чем я могу даже подключиться. ssh не затрагивается. Я знаю, что это nginx, потому что, когда я останавливаю nginx, проблема с sftp мгновенно исчезает. Однако сам nginx практически не имеет задержки во время этих «эпизодов».

Это давняя проблема с моим сервером, и недавно я решил решить ее раз и навсегда. Вчера я начал подозревать, что огромный объем HTTP-трафика в сочетании с большей задержкой, вызванной нехваткой восходящей полосы пропускания, вытеснял мой sftp-трафик. я использовал tc чтобы добавить некоторые приоритеты:

/sbin/tc qdisc add dev eth1 root handle 1: prio 
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1

К сожалению, несмотря на то, что я вижу, что пакеты sftp накапливаются в первом приоритете:

class prio 1:1 parent 1: 
 Sent 257065020 bytes 3548504 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
class prio 1:2 parent 1: 
 Sent 291943287326 bytes 206538185 pkt (dropped 615, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
class prio 1:3 parent 1: 
 Sent 22399809673 bytes 15525292 pkt (dropped 2334, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

... задержка при подключении по-прежнему недопустима. Вот несколько красивых графиков, которые я только что сделал, пытаясь что-то связать с задержкой sftp:

Вот задержка sftp из другого места. У меня установлен тайм-аут 25 секунд. Для меня неприемлемо все, что превышает обычные 1-2 секунды, необходимые для подключения и загрузки крошечного файла. Вы можете увидеть, как ночью все становится нормально, а днем ​​снова возникает задержка.

Содержание /proc/net/sockstat. Обратите внимание на очевидную корреляцию задержки sftp с использованием памяти tcp. Понятия не имею, что это может значить.

Вывод модуля состояния заглушки nginx. Здесь нечего смотреть ...

Выход netstat -tan | awk '{print $6}' | sort | uniq -c. Опять кажется плоским.

Так почему нет tc работает на меня? Нужно ли мне на самом деле ограничивать пропускную способность, а не просто устанавливать приоритеты для порта 22? Или это tc неправильный инструмент для работы, и я полностью упускаю настоящую причину плохой производительности sftp?

Выход uname -a:

Linux [redacted] 3.2.0-0.bpo.2-amd64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux

Я запускаю nginx 1.2.2 со скомпилированным потоковым модулем mp4.

Изменить 2012/07/31:

ewwhite спросил, близок ли я к пределу пропускной способности или достиг ли его. Я проверил, и, похоже, есть корреляция (хотя и не идеальная) между пределом в 100 Мбит и плохой задержкой sftp:

Но почему же трафик sftp (связанный с портом 22) не будет иметь более высокий приоритет, чем трафик http во время этих эпизодов?

Редактировать 2012/07/31 # 2

При сборе данных о задержке sftp / scp я заметил закономерность, как показано на графике ниже (зеленые линии, которые я добавил):

Два кластера - за вычетом «базовой» задержки, они составляют ~ 5 и ~ 10 секунд. Вы также можете довольно четко увидеть их на приведенном выше графике задержки sftp в гораздо большем масштабе времени. Откуда это 5-секундное число?