ruby-on-rails - Heroku 上偶尔出现 Rack::Timeout::RequestTimeoutException

Question

我注意到在 1-5 分钟的时间段内，1-20% 的请求屈服于 Rack::Timeout::RequestTimeoutException。这种情况大约每隔几个小时发生一次。没有 n+1 查询，也没有任何丢失的索引 AFAIK。我们使用的是 Standard-7 Postgres，具有 120GB RAM 并且连接还没有达到极限。还有哪些其他事情我可以四处窥探以了解问题所在？谢谢!

这是一个请求队列时间激增的示例。

示例日志:

source=DATABASE
sample#current_transaction=160483065.0
sample#db_size=35361812244.0bytes
sample#tables=29
sample#active-connections=60
sample#waiting-connections=0
sample#index-cache-hit-rate=0.99897
sample#table-cache-hit-rate=0.99893
sample#load-avg-1m=0.07375
sample#load-avg-5m=0.06
sample#load-avg-15m=0.05375
sample#read-iops=0
sample#write-iops=0
sample#memory-total=125650852.0kB
sample#memory-free=75423472.0kB
sample#memory-cached=46423528.0kB
sample#memory-postgres=485000.0kB

Answer 1

我假设您正在运行多个网络测功机但没有工作测功机。并且您正在使用经过优化以服务于多个并发连接的 unicorn/Goliath 服务器？

您没有看到 Postgres 或 ruby​​ 尖峰。您看到排队高峰。没有看到您的实际设置。您可能是 heroku routing 随机选择算法的受害者.

您是否有可以将任何长时间运行的任务推送给后台工作人员？其他请求可能落后了。或者是否有一个请求挂起，导致它后面的任何东西超时。这些可能很难在日志本身中发现。

上面文章中概述的一些解决方案。在请求上添加硬超时。强制终止任何长时间运行的请求。这将使您的日志更好地显示任何错误的确切位置，而不仅仅是链式 react 。

根据采样率，您所拥有的图表有时可能有点难以解释，尤其是在不深入研究测功机本身的相关图表的情况下。查看graphite在每个测功机的基础上查看指标。

还有一些其他事情可以在您不注意的情况下阻止工作人员。

DNS 查询。你如何查找你的主机名？对于外部服务/数据库实例等，这可能很难发现，并且可能会显示在图表的 ruby 部分下方。所以可能不是这里的问题。

连接池。在这种情况下似乎不太可能，因为您已经排除了它。但是检查工作人员的数量与可用的连接数。