我有一台运行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

不幸的是,即使我可以看到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}’|排序| uniq -c.再次,似乎持平.

那么为什么tc不适合我呢？我是否需要实际限制带宽而不是仅仅优先考虑端口22的进出？或者是错误的工具,我完全错过了糟糕的sftp性能的真正原因？

uname -a的输出：

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

我正在使用编译的mp4流模块运行Nginx 1.2.2.

编辑2012/07/31：

ewwhite问我是否接近或达到我的带宽限制.我检查过,在100 mbit限制和糟糕的sftp延迟之间似乎存在相关性(尽管不是完美的)：

但是,为什么在这些剧集期间,sftp流量(与端口22相关联)的优先级不高于http流量？

编辑2012/07/31#2

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

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