nginx在繁忙时间打破sftpstream量 – 是答案?

这可能是我以前(未回答)问题的延续,因为潜在的原因可能是相同的。

我有一个运行nginx和sshd的Linux服务器。 这是一个共享的100mbit / s的无限量的链接。 在“高峰时段”(基本上,在美国白天),SFTP性能变得非常糟糕,有时甚至在连接之前就超时。 ssh不受影响。 我知道这是nginx,因为当我停止nginx时,sftp的问题会立即消失。 然而,在这些“事件”中,nginx本身基本上没有延迟。

这是我的服务器一个长期存在的问题,我最近着手处理一劳永逸。 昨天我开始怀疑,由于缺乏上行带宽导致的大量的httpstream量以及更大的延迟导致了我的stream量。 我用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 

不幸的是,尽pipe我可以看到在第一个prio中积累的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输出 netstat -tan | awk '{print $6}' | sort | uniq -c netstat -tan | awk '{print $6}' | sort | uniq -c 。 再次,似乎是平坦的。

那么为什么不为我工作? 我是否需要真正限制带宽,而不是仅仅优先考虑端口22? 或者是这个工作的错误工具,我完全错过了不好的SFTP性能的真正原因?

uname -a输出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,编译了mp4stream模块。

编辑2012/07/31:

ewwhite问我是否在我的带宽限制附近。 我检查了一下,似乎有一个关联(虽然不是一个完美的)在100 mbit的限制和不好的sftp延迟之间:

但是,为什么在这些情节中,stream量(与端口22相关)不会优先于HTTPstream量呢?

编辑2012/07/31#2

在收集sftp / scp延迟数据时,我注意到了一个模式,如下图所示(我添加的绿线):

两个群组 – 减去“基线”潜伏期,他们在〜5和〜10秒。 您也可以在更大的时间尺度上,在上面的sftp延迟图上清楚地看到它们。 这个5秒的数字来自哪里?

一些东西跳出来对我…

  • 你没有达到或接近带宽限制,是吗?
  • 你在慢sftp性能期间查看系统熵池的水平(检查/proc/sys/kernel/random/entropy_avail )? 例如你的nginx会话是否处理了很多SSL请求? 这可以对使用encryption的其他服务产生明确的影响。
  • 有一些sysctl.conf调优参数可以帮助(TCP窗口大小?),但SFTP不是非常有效的。 是scp一个选项? 文件有多大?
  • DNS? 你遇到反向查询延迟? 你有任何控制谁连接到你? 如果可以预测的话,请在/etc/hosts为源IP尝试一个存根条目,看看是否有帮助。

所以事实certificate,我至less有三个不同的问题相互掩盖。 以下是我所做的解决问题的方法:

  1. 在端口22上优先考虑ICMP和input/输出stream量(如上面的问题所示)。 这提高了sftp响应(例如, ls )以及在高峰时间的传输吞吐量。

  2. 通过Debian backports安装haveged包,解决熵不足的问题。 这解决了“在select() ”问题上挂了几分钟的问题。 ewwhite ++

  3. UseDNS no添加到/etc/ssh/sshd_configUseDNS no sshd 。 这解决了在高峰时间间隔5秒的sftp延迟。 谢尔盖·弗拉索夫++

剩余的奥秘:

  • 我的主机最初为我configuration了/etc/resolv.conf ,并将其两个名称服务器添加为主节点。 可以理解的是,这些名称服务器中的一个或多个在高峰时间(即在美国白天)过载,导致我在sftp延迟图上注意到的5秒间隔延迟。 但是,为什么每次我传输文件时sftp执行反向DNS查找? 当初始连接上的反向查找超时,然后在第一次传输时,这些简单的情况就是这样: sftp子系统一次又一次地尝试不能逆转我的IP? 在这种情况下,系统是否尝试使用辅助名称服务器? 无论如何,我现在已经在我的ISP的重载服务器上添加了一些知名的公用名称服务器作为初始服务器,所以在这个服务器上运行的其他可能的应用程序在高峰时段不会遇到与DNS有关的问题。

  • 什么是消耗我的服务器熵? 我找不到任何证据表明股票nginx(服务静态文件)调用rand() ,但似乎正是发生了什么事情。 是文件系统(ext3 / 4)还是内核涉及的另一部分?

无论如何,现在这已经够好了。 感谢这个社区,我解决了十多年来unix web服务器pipe理中遇到的最恼人和最持久的问题之一。