重负载下扭曲连接超时

Twisted connections timeout under heavy load

我们有一个 Django 网络应用程序,可以为中等数量的用户提供服务,运行 在具有 8 个内核和至少 32GB RAM 的 Ubuntu 机器上。我们对用户通过浏览器连接没有任何问题。但是,在后端(在同一台服务器上)我们也是 运行 一个扭曲的服务器。 Django webapp 尝试连接到我们扭曲的服务器,但在大约 1100-1200 个这样的连接之后(包括一堆与后端其他设备的持久连接),所有连接都开始超时。我们扭曲的服务器在低负载下运行良好,但现在服务器似乎无法处理来自 Django 的任何新连接。所有连接超时。我们没有发现我们的代码有任何明显的错误(我们已经研究了几年,所以它应该非常稳定)。我们已经在 /etc/security/limits.conf 中将我们的软和硬 ulimits 设置为 50000/65000 并且我们已经将 somaxconn 提高到 65536。下面列出了我们扭曲过程的限制打印。前 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

Twisted 是您的应用程序的薄 shell。当出现性能问题时,几乎总是问题出在应用程序内部的某个地方,而不是在 Twisted 中。所以这个问题没有统一的答案。

也就是说,您可以使用一些调查技巧。您的 Twisted 进程是否消耗了 100% CPU?如果是这样,那么您将需要以某种方式将其拆分为多个进程(使用 spawnProcesssendFileDescriptoradoptStreamPort 以允许 I/O 在子进程中完成)。如果不是,那么您的问题可能是一些无意的阻塞 I/O 阻止反应器为请求提供服务:您可以使用类似 twisted_hang 的东西来诊断反应器获得 "stuck" 的热点。 =15=]

也有可能问题出在连接的 Django 端。然而,由于没有关于 Django 如何建立这些联系的信息,我什至无法猜测。