Python WSGI延迟峰值

使用Apache下的mod_wsgi，以守护进程模式，在Ubuntu上，为来自python的rest api调用提供服务

一般来说，通话时间约为0.5秒，但偶尔会在5秒达到峰值。我们正在运行大约40个守护进程，所有进程都限制在一个线程内。服务器有很多内存

这5秒的峰值似乎出现在即使rest调用微不足道的情况下，也比睡眠时的“hello world”稍多一些

---

我怀疑wsgi进程正在被python或操作系统替换掉，但我几乎没有证据支持这一点。我还尝试将nginx/uwsgi与never swap参数一起使用，但这并没有解决问题。

当您最初似乎在谈论mod_wsgi时，为什么同时提到mod_wsgi和uwsgi，因为您说的是“怀疑是uwsgi进程”？它们是不同的东西。顺便说一句，40个进程相当多，取决于CPU的数量可能过多，这本身就是一个问题。为什么不使用多线程进程？对于uWSGI，您可以通过Stats Server获得workers输出的一些详细状态信息：-此外，Apache具有mod_状态，并且在您的服务器上运行一些基本的监视，如Zabbix或Munin，提供操作系统活动的信息，并帮助解决类似问题。Graham I更正了对uWSGI进程的提及。我分别测试了apache/mod_wsgi和nginx/uwsgi，两者都有问题。我认为CPU没有负载。是的，我可以看到线程可能会有所帮助，但这不是我的代码，python也不是我的语言，我相信我需要完全验证代码是否是线程安全的，这在其他语言中是非常重要的。仅在Apache中使用mod_status不太可能有帮助，因为它的报告有点粗糙。mod_wsgi的最新版本为Apache整体内置了监控功能，这有助于更好地利用mod_status所基于的底层数据，此外，尚未发布的mod_wsgi版本还具有更多与守护进程相关的监控功能。唯一的问题是，并没有一个适配器可以将这一切传输到一个单独的监控系统，所以需要整合一些东西来实现这一点。