nginx 在高峰时段破坏 sftp 流量 - tc 是答案吗?

nja*_*nke 5 linux nginx qos sftp tc

这可能是我之前(未回答)问题的延续,因为根本原因可能是相同的。

我有一台运行着 nginx 和 sshd 的 Linux 服务器。它位于共享的 100mbit/s 未计量链路上。在“高峰时段”(基本上是在美国的白天),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
Run Code Online (Sandbox Code Playgroud)

不幸的是,即使我可以看到 sftp 数据包在第一个 prio 中累积:

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 
Run Code Online (Sandbox Code Playgroud)

...连接时延迟仍然不可接受。这是我刚才在尝试将某些内容与 sftp 延迟相关联时制作的一些漂亮的图表:

这是来自不同位置的 sftp 延迟。我将超时设置为 25 秒。任何比连接和下载小文件所需的正常 1-2 秒时间更长的事情对我来说都是不可接受的。您可以看到它如何在夜间变得正常,然后在白天再次出现延迟。

的内容/proc/net/sockstat。请注意 sftp 延迟与 tcp 内存使用之间的明显相关性。不知道这可能意味着什么。

nginx 的 stub-status 模块的输出。这没东西看 ...

的输出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 秒的数字是从哪里来的?

eww*_*ite 2

有几件事让我突然想到......

  • 您没有超出或接近带宽限制,是吗?
  • 您是否在 sftp 性能缓慢期间查看过系统熵池/proc/sys/kernel/random/entropy_avail级别(检查)?例如,您的 nginx 会话是否执行大量 SSL 请求?这可能会对其他使用加密的服务产生明显的影响。
  • 有一些sysctl.conf调整参数可能会有所帮助(tcp 窗口大小?),但 sftp 效率不是很高。是scp一个选项吗?文件有多大?
  • 域名系统?您是否遇到反向查找延迟?您可以控制谁连接到您吗?如果可以预测,请尝试源 IP 的存根条目,/etc/hosts看看是否有帮助。

  • 5 秒是通常的 DNS 查询超时,但如果这是问题所在,则所有 SSH 连接都应该经历相同的延迟,而不仅仅是 sftp/scp。或者也许您的纯 ssh 连接碰巧使用了“ControlMaster”功能,从而避免了在重用连接时进行反向 DNS 查找? (2认同)