我们有一个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
答案 0 :(得分：0)
Twisted是一个围绕您的应用程序的薄外壳。当出现性能问题时，问题几乎总是在应用程序内部而不是Twisted中。所以这个问题没有一般的答案。
尽管如此，您可以使用几种调查技巧。你的Twisted进程是否消耗100％的CPU？如果是这样，那么您将需要以某种方式将其拆分为多个进程（使用spawnProcess，sendFileDescriptor和adoptStreamPort以允许在子进程中完成I / O）。如果没有，那么你的问题可能是一些无意的阻塞I / O阻止了反应堆为请求提供服务：你可能会使用类似twisted_hang的东西来诊断反应堆所在的热点＆＃34;卡住了＃34;。
此问题也可能出现在Django的连接方面。但是，由于没有关于Django如何建立这些联系的信息，我甚至可以猜到它。