我在远程服务器中有两个Rails应用程序（生产和登台环境）。
我目前遇到一个奇怪的问题，Puma在部署完成后（通过上限部署）有时给我超时。这种情况已经发生了很长一段时间，而且越来越频繁。每当发生这种情况时，我需要重新启动Puma服务器（来自cap puma:stop和cap puma:start），或手动执行kill -9 <pid of puma instance>。但是，在这两种情况下，我首先需要rm puma.sock目录shared/tmp/sockets。
另一方面，我的生产环境没有遇到此问题。它们之间的区别只是提交的数量，我的暂存环境是几个（约50）提交。早在我将staging合并到生产并部署时，生产中出现了同样的问题。所以我将我的作品回滚到之前的版本，重新启动了Puma，问题就消失了。
注意：cap puma:restart以某种方式无法解决此问题;我必须杀死当前的Puma实例，然后开始一个新实例以使这个问题消失。
我目前的设置是：
在错误发生时，Rails日志中没有任何内容，但Nginx记录了一些错误：
upstream timed out (110: Connection timed out) while reading response header from upstream 等待60秒后，会显示500页。 recv() failed (104: Connection reset by peer) while reading response header from upstream 页面立即显示500。 connect() to unix:/var/deploy/medictrust-staging/shared/tmp/sockets/puma.sock failed (111: Connection refused) while connecting to upstream 页面立即显示500。 上述错误随机发生;有时它的连接超时，有时连接被拒绝..但最常见的是连接超时。
奇怪的是，如果我通过cURL 访问我的应用程序，Puma没有超时。在Puma或Nginx配置中没有进行任何更改，因此是否可能是由应用程序代码引起的？
如何让这个问题彻底消失？
答案 0 :(得分：0)
对我来说，Web服务器超时是因为整个数据库都存在长时间运行的查询，这会占用可用的连接并使Puma等待新的连接可用。
作为急救，我重新启动了我的MySQL服务器，它立即起作用。我很遗憾没有记录慢查询;因为该查询必须是我的Rails应用程序中的一些错误代码的结果。
此外，这个SO答案也有帮助：Getting “Lock wait timeout exceeded; try restarting transaction” even though I'm not using a transaction