Heroku 上的偶尔 Rack::Timeout::RequestTimeoutException答案

【问题标题】：Occasional Rack::Timeout::RequestTimeoutException on HerokuHeroku 上的偶尔 Rack::Timeout::RequestTimeoutException
【发布时间】：2016-06-01 11:27:03
【问题描述】：

我注意到在 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

【问题讨论】：

请包括 (1) 数据库主机上的 CPU 使用率，(2) 数据库 WAL 和数据所在磁盘的延迟/IO 队列。
我不确定我能否获得这些数据。似乎其中大部分是从 Heroku Postgres 中抽象出来的。我刚刚上传了带有示例日志的帖子，但它们看起来并没有什么不同。
heroku pg:diagnose --app <your_app> 的输出是什么？
RED: Hit Rate Name Ratio ----------------------------- ------------------ public.tracks 0.9678830033375656 GREEN: Connection Count GREEN: Long Queries GREEN: Idle in Transaction GREEN: Bloat GREEN: Blocking Queries GREEN: Sequences GREEN: Load
你运行了多少台测功机？

标签： ruby-on-rails postgresql heroku

【解决方案1】：

我假设您正在运行多个 web dynos 而没有 worker dynos。并且您正在使用经过优化以服务多个并发连接的 unicorn/Goliath 服务器？

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

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

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

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

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

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

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

【讨论】：