我对托管 Web 应用程序有点陌生，但是有一个正在运行的 Python 应用程序，它使用 webpy 部署在带有 mod_wsgi 的 apache 服务器上。它似乎运行得很好，除了当我使用该应用程序时，apache 似乎经常从头开始随机重新加载 webpy 应用程序 (app.py)。
它加载速度很快，因此是无缝的，但它会重置应用内部的所有用户数据。这应该发生吗？我是否需要将所有数据连续写入文件？如果没有，我怎样才能让应用程序一直运行直到我想停止它？
谢谢！
【问题讨论】：
标签： python apache mod-wsgi restart web.py
首先，如果可能的话，最好尽可能多地存储您的数据客户端，这可以让生活更轻松。存储在数据库中或写入磁盘也是有效的选项，但请记住，数据库设计为可同时访问，而单个文件则不能，因此您需要仔细设计存储机制。
某些服务器被配置为自动终止空闲进程以节省资源。我不能肯定是这样，但您可以在 httpd 配置中检查 WSGIDaemonProcess 的以下设置：
最大请求数=nnn
定义守护进程在关闭和重新启动之前应处理的请求数限制。将此设置为非零值有利于限制进程可能因（意外）内存泄漏而消耗的内存量。
如果未定义此选项，或定义为 0，则守护进程将是持久的，并将继续为请求提供服务，直到 Apache 自身重新启动或关闭。
inactivity-timeout=sss (2.0+)
定义当守护进程进入空闲状态时，在关闭和重新启动守护进程之前允许经过的最大秒数。出于此选项的目的，空闲意味着在定义的时间段内没有接收到新请求，或者当前请求没有尝试读取请求内容或生成响应内容。
此选项的存在是为了允许重新启动在守护进程中运行的不常用的应用程序，从而允许回收使用的内存，进程大小会在任何应用程序加载或处理请求之前回落到初始启动大小。
死锁超时=sss (2.0+)
定义在检测到 Python GIL 上的潜在死锁之后，在关闭和重新启动守护进程之前允许经过的最大秒数。默认值为 300 秒。
此选项的存在是为了解决由于 rouge Python C 扩展模块在进入阻塞或长时间运行的操作时未正确释放 Python GIL 而导致守护进程冻结的问题。
shutdown-timeout=sss
定义在等待守护进程由于达到最大请求数或不活动超时而正常关闭时允许通过的最大秒数，或者当用户启动的 SIGINT 信号被发送到守护进程时。当达到这个超时时间时，即使仍然有活动的请求或者它仍在运行 Python 退出函数，守护进程也会被强制退出。
如果未定义此选项，则关闭超时将设置为 5 秒。请注意，当 Apache 本身停止或重新启动时，此选项不会更改应用于守护进程的关闭超时。该超时值在 Apache 内部定义为 3 秒，并且不能被覆盖。
来源：http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives
【讨论】：