在高峰时期nginx clobbering sftp流量 - 是答案吗?

Modified on: Sat, 01 Jun 2019 00:00:03 +0800

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

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

我正在使用编译的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秒的数字来自哪里?

作者:Community,njahnke

最佳答案

有几件事情向我跳出来......

  • 你没有达到最大限度或接近带宽限制,是吗?
  • 您是否在慢速期间查看了系统熵池的级别sftp性能(检查/proc/sys/kernel/random/entropy_avail)?例如。您的nginx会话是否正在执行大量SSL请求?这对使用加密的其他服务有明显的影响。
  • 有一些sysctl.conf调整参数可能会有所帮助(tcp窗口大小?),但sftp并不是非常有效。 scp是一个选项吗?文件有多大?
  • DNS?您是否遇到反向查找延迟?你能控制谁和你联系吗?如果它是可预测的,请在/etc/hosts中尝试源IP的存根条目,看看是否有帮助。
作者:,ewwhite

相关问答

添加新评论