☰

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

tag-icon • tag-icon linux nginx sftp qos tc
nginx 在高峰时段破坏 sftp 流量-tc 是答案吗？

这可能是我之前的问题（尚未回答）因为根本原因可能是一样的。

我有一台 Linux 服务器，上面运行着 nginx 和 sshd。它位于一条共享的 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

不幸的是，尽管我可以看到 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

... 连接时延迟仍然不可接受。以下是我刚刚在尝试将某些内容与 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 mbit 限制和糟糕的 sftp 延迟之间似乎存在关联（尽管不是完全关联）：

但是，为什么在这些事件中 sftp 流量（与端口 22 相关）的优先级没有高于 http 流量呢？

编辑 2012/07/31 #2

在收集 sftp/scp 延迟数据时，我注意到了一种模式，如下图所示（我添加的绿线）：

两个集群 - 减去“基线”延迟，它们分别为 ~5 秒和 ~10 秒。您还可以在上面的 sftp 延迟图上以更大的时间尺度清楚地看到它们。这个 5 秒的数字是从哪里来的？

答案1

有几件事让我印象深刻...

  • 您没有达到或接近带宽限制，是吗？
  • 你看过系统了吗熵池在 sftp 性能较慢期间，/proc/sys/kernel/random/entropy_avail您的 nginx 会话是否执行大量 SSL 请求？这会对使用加密的其他服务产生明显影响。
  • 有一些sysctl.conf调整参数可能会有所帮助（tcp 窗口大小？），但 sftp 效率不高。有scp选择吗？文件有多大？
  • DNS？您是否遇到了反向查找延迟？您是否可以控制谁在连接您？如果可以预测，请尝试为源 IP 设置存根条目，/etc/hosts看看是否有帮助。

答案2

事实证明，我至少遇到了三个不同的问题，它们互相掩盖。以下是我解决问题的方法：

  1. 优先处理端口 22 上的 ICMP 和传入/传出流量（如我上面的问题所示）。这可提高 sftp 响应能力（例如ls），还可提高高峰时段的传输吞吐量。

  2. 通过 Debian backport安装软件包来解决熵短缺问题haveged。这解决了“在…停留几分钟select()”问题。ewwhite++

  3. 添加UseDNS no并/etc/ssh/sshd_config重新哈希sshd。这解决了高峰时段每隔 5 秒出现一次 sftp 延迟的问题。Sergey Vlasov++

尚存谜团：

  • 我的主机最初/etc/resolv.conf为我配置了两个名称服务器作为主服务器。可以理解的是，在高峰时段（即美国的白天），这些名称服务器中有一个或多个超载，导致我在 sftp 延迟图上注意到 5 秒间隔延迟。但是，为什么执行sftp反向 DNS 查找每次我传输文件？这些情况是否只是在初始连接时反向查找超时，然后在第一次传输时，子系统sftp再次尝试并再次无法反向我的 IP？在这种情况下，系统是否不尝试辅助名称服务器？无论如何，我现在已将一些知名的公共名称服务器添加为 ISP 过载名称服务器的主要服务器，因此在同一台服务器上运行的其他可能应用程序在高峰时段不会遇到 DNS 问题。

  • 是什么在消耗我的服务器上的熵？我找不到任何证据表明普通的 nginx（提供静态文件）调用rand()，但这似乎正是正在发生的事情。是文件系统（ext3/4）还是内核的另一部分以某种方式参与其中？

无论如何，现在这样已经足够好了。感谢这个社区，我得以解决十多年来我遇到的最烦人、最持久的问题之一。

相关内容