在Heroku上偶尔出现Rack :: Timeout :: RequestTimeoutException

Question

我注意到1-5分钟的时间段，其中1到20％的请求产生Rack::Timeout::RequestTimeoutException。这种情况每隔几个小时就会发生一次。没有n + 1个查询，并且没有任何缺失索引AFAIK。我们使用的是Standard-7 Postgres，配备120GB内存，连接数量尚未达到最大值。我可以撬开什么其他东西来看看问题是什么？谢谢！

以下是请求队列时间激增的示例。

示例日志：

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

我假设您正在运行多个网络dynos并且没有工作人员dynos。并且您正在使用经过优化以提供多个并发连接的独角兽/ Goliath服务器？

你没有看到Postgres或红宝石峰值。你看到排队尖峰。没有看到您的实际设置。您可能是heroku routing的随机选择算法的受害者。

您是否有任何可以推送给后台工作人员的长期任务？其他请求可能正在落后。或者是否有挂起的请求，导致其后面的任何内容超时。这些可能很难在日志本身中发现。

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

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

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

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

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