即使我对发送的请求保持限制，我的服务器也会过载

Question

我在Heroku上有一台服务器 - 3个dynos，每个2个进程。

服务器完成两件事：

1. 根据存储在postgresql数据库中的数据响应来自浏览器的请求（AJAX和一些网页）
2. 它公开了一个REST API来更新数据库中的数据。此API由另一台服务器调用。调用速率是有限的：另一台服务器只通过一个具有单个工作线程的队列调用我的服务器，这可以确保其他服务器不会向我的服务器并行发出多个请求（我确认它确实没有）。

当我查看新遗物时，我看到下面的图表，这表明即使我将其他服务器最多保留在一个并行请求中，它仍然会加载我的服务器，从而创建峰值。



我希望由于来自其他服务器的调用率有限，我的服务器不会过载，因为请求只会在前一个请求结束时启动（我猜测可能数据库过载了它获得更新请求并返回但在此之后继续处理。

• 有什么可以解释这种行为？

• 为了了解发生了什么，我还能在哪里查看？

• 有没有办法避免这种行为？

Answer 1

这项调查可能有很多方向，但是从你的截图和一些推论中，我有两个猜测。

• 长查询 - 如果您的其他服务器或浏览器偶尔遇到慢查询，您会看到此图表。如果它只是一个长读取查询并且您的数据库没有达到其限制，它应该只影响运行查询的进程，但如果查询采用独占锁定，则所有dynos都必须等待它。由于尖峰是如此规则，首先想到你按计划运行的任何东西 - 如果节奏匹配，你可能有你的罪魁祸首。接下来要做的就是运行heroku pg:long-running-queries和heroku pg:seq-scans。前者显示可能需要优化的查询，后者显示可以使用不同查询或更好的索引修复的全表扫描。您可以在NewRelic的数据库选项卡中找到类似的信息，该选项卡具有时间和吞吐量图表，您可以尝试再次匹配您的排队峰值。最后，查看NewRelic的“交易”选项卡。
  • 有多种方式可以排序 - 最慢的平均响应时间可能会有所帮助，但请查看所有选项，看看是否有任何交易突出。
  • 点击可疑交易，然后查看右侧的图表。如果您看到峰值与排队累积相匹配，那可能就是这样，但由于它看起来会影响您的整个网站，请注意看到相关减速的多个交易。
  • 查看底部的交易记录。那里需要很长时间才能运行的东西就像接近吸烟枪一样。这应该与pg:long-running-queries相关联。
  • 查看图表和事务跟踪之间的细分表。检查需要很长时间（例如，2秒外部请求）或经常发生的事情（例如，每个请求呈现2500次的部分）。这些是缓存或优化的地方。
• 垃圾收集 - 这是不太可能的，因为Ruby GCs一直没有理由它会在常规节奏上显示尖峰，但如果有常规请求分配大量的物体，建造物体和清理它们都需要时间。它只会同时影响一个dyno，并且会在NewRelic调查中与长时间或高度重复的查询相关联。您可以在NewRelic的Ruby VM选项卡中看到有关此内容的一些统计信息。

看看你的dyno和数据库内存使用情况。两者都打印到Heroku logs，如果添加Librato，它们会构建一些非常有用的自动图表。如果您的dyno正在交换，性能将受到影响，您应该升级到更大的dyno或每个dyno运行更少的进程。进程通常会在内存运行时累积内存，并且永远不会释放尽可能多的内存，因此调整它以便在重新启动之前，您的dyno正好位于其可用RAM之下。类似地，对于数据库，如果您在那里进行交换，查询性能将受到影响，您应该进行升级。

其他可能的事情，但可能不是这种情况：

• 睡觉的dynos -Heroku如果一段时间没有提供请求，就会让dyno进入睡眠状态，但前提是你只有1个dyno在运行。你有3个，所以这不是它。
• Web服务器并发 - 如果在任何给定时刻，请求多于可用进程，请求将排队。显而易见的解决方法是增加可用的dynos /进程，这会给你的数据库带来更多的负担，并可能将问题转移到那里。由于每次都会看到一些常规请求，我猜测请求量很低，这也不是你的问题。
• Heroku不稳定 - 有时，由于没有明显原因，Heroku开始排队请求的次数超出预期，并且不会在status.heroku.com报告任何问题。重新启动dynos通常会在Heroku直接恢复时暂时修复。