我正在使用Starman(v0.4014)和ngynx作为前端代理运行Dancer(v1.3202)应用程序.我注意到我的负载平衡器每隔几个小时出现一次巨大的延迟峰值,并想知道是否工作人员达到了他们的请求限制并重新启动.延迟从平均30ms到1000ms或更长.我检查了MongoDB,没有长时间运行的查询. –max-requests对工人实际做了什么以及当工人达到这个限制时会发生什么？
来自starman –help：
–max-requests
Number of the requests to process per one worker process. Defaults
to 1000.
这意味着每个工作程序在处理了许多请求后将退出.然后,主过程将为每个退出的工人启动一个全新的工人,根据 – 工人设置维护工人的数量.
使用–max-requests通常是一件好事,特别是如果您的应用程序不是唯一运行在盒子上的东西,因为perl(众所周知)不会回馈它使用的内存.这种工作进程的回收是starman可以为其他进程提供内存的方式.如果您的应用实际上泄漏了内存,这也有助于保持您的应用程序以良好的性能运行,而不是您的应用最终消耗所有内存并且需要被操作系统杀死.
–max-requests设置的最佳值是多少？
除非您有充分的理由进行更改,否则应将其保留为默认值1,000.如果你的应用程序是盒子上运行的唯一东西,并且你确定它没有泄漏,你可以尝试使用更高的值来减少工作人员的回收.如果您知道您的应用程序漏洞,您可能希望使用较低的值来更频繁地回收工作人员.但是,通常这种设置实际上对性能的影响非常小.
也就是说,如果你的工作人员将内容缓存在内存中,回收工作人员可能会对虚假的缓慢请求负责,因为新工作人员需要花一些时间来重建这些缓存,但可能还有许多其他可能的解释.您需要进行一些分析,以找出真正导致您所看到的特定缓慢的原因.
