Heroku上的临时Rack::Timeout::RequestTimeoutException

Question

我注意到在1-5分钟的时间内，任何地方都有1- 20%的请求被Rack::Timeout::RequestTimeoutException接受。这种情况大约每隔几个小时发生一次。没有n+1查询，也没有任何缺失的索引AFAIK。我们使用的是Standard-7 Postgres，内存为120‘t，连接还没有达到最大。我还可以查看其他什么东西来查看问题所在？谢谢!

这里有一个请求队列时间峰值的例子。

示例日志：

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

我假设您正在运行多个web dynos，而没有worker dynos。以及您正在使用的独角兽/Goliath服务器是否经过优化，可以为多个并发连接提供服务？

你看不到Postgres或ruby尖峰。您可以看到队列峰值。而没有看到你的实际设置。你可能是heroku routing随机选择算法的受害者。

您是否有任何长期运行的任务，您可以推送到后台工作程序？其他请求可能会落后。或者是否存在挂起的请求，导致其后面的任何内容超时。这些可能很难在日志本身中找到。

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

根据采样率，您所拥有的图形有时可能很难解释，特别是在没有深入研究dyno本身的相关图形的情况下。请查看graphite以查看每个dyno的指标。

其他一些可能会在你没有注意到的情况下阻止工人的事情。

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

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