重负载下的Twisted连接超时

时间:2015-07-22 15:33:36

标签: django sockets ubuntu network-programming twisted

我们有一个Django网络应用程序,为中等数量的用户提供服务,在具有8个内核和至少32GB RAM的Ubuntu机器上运行。用户通过浏览器连接时没有问题。但是,在后端(在同一台服务器上),我们也运行一个扭曲的服务器。 Django webapp尝试连接到我们的扭曲服务器,但在大约1100-1200个这样的连接(包括后端上其他设备的一堆持久连接)之后,所有连接都开始超时。我们的扭曲服务器在低负载下运行良好,但现在服务器似乎无法处理来自Django的任何新连接。所有连接都超时。我们没有看到任何明显错误的代码(我们已经工作了几年,所以它应该非常稳定)。我们已经将/etc/security/limits.conf中的软和硬ulim设置为50000/65000,并且我们将somaxconn提高到65536.下面列出了我们的扭曲过程的限制打印。 tope 25进程中的文件总数刚刚超过5000.遗憾的是,我们仍然无法获得超过大约1100-1200个连接到我们的扭曲服务器的连接。我们应该注意什么才能使我们的扭曲连接再次开始连接?是否还需要更改其他sysctl或其他Ubuntu Linux参数?我们需要更改扭曲的参数吗?

Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             465901               465901               processes
Max open files            50000                65000                files
Max locked memory         65536                65536                bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       465901               465901               signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

1 个答案:

答案 0 :(得分:0)

Twisted是一个围绕您的应用程序的薄外壳。当出现性能问题时,问题几乎总是在应用程序内部而不是Twisted中。所以这个问题没有一般的答案。

尽管如此,您可以使用几种调查技巧。你的Twisted进程是否消耗100%的CPU?如果是这样,那么您将需要以某种方式将其拆分为多个进程(使用spawnProcesssendFileDescriptoradoptStreamPort以允许在子进程中完成I / O)。如果没有,那么你的问题可能是一些无意的阻塞I / O阻止了反应堆为请求提供服务:你可能会使用类似twisted_hang的东西来诊断反应堆所在的热点"卡住了#34;。

此问题也可能出现在Django的连接方面。但是,由于没有关于Django如何建立这些联系的信息,我甚至可以猜到它。