这是非常具体的，但我会尽量简短：
我们在Heroku上运行了一个Django应用。三台服务器：
1.测试（1个网，1个celery dyno）
1.培训（1个网站，1个celery dyno）
- prod（2 web，1 celery dyno）.
我们使用Gunicorn，每个dyno上有gevents和4个worker。
我们正在经历零星的高服务时间。以下是Logentries的一个例子：
High Response Time:
heroku router - - at=info
method=GET
path="/accounts/login/"
dyno=web.1
connect=1ms
service=6880ms
status=200
bytes=3562我已经在谷歌上搜索了好几个星期了。我们无法随意复制，但每天会遇到0到5次这些警报。注意事项：
- 在所有三个应用程序上安装插件（所有应用程序都运行类似的代码）
- 在不同的页面上运行，包括简单的页面，如404和/admin
- 在随机时间
- 具有不同吞吐量的交换机。我们的一个示例每天只驱动3个用户。这与睡眠中的动态人无关，因为我们使用New Relic ping，问题可能会在会话中发生
- 不能随意繁殖。这个问题我亲身经历过一次。点击一个通常在500毫秒内执行的页面会导致30秒的延迟，最终导致Heroku的30秒超时的应用程序错误屏幕
- 高响应时间从5000 ms-30000 ms不等。
- 新遗迹并没有指向一个具体的问题。以下是过去几次交易和时间：
- RegexURLResolver.resolve
4,270ms - SessionMiddleware.process_request
2,750ms - 渲染login.html
1,230ms - WSGI
1,390ms - 以上是简单的调用，通常不需要那么长的时间
我已经缩小到： - This article on Gunicorn and slow clients
- 我见过这个问题发生在慢客户端，但也在我们的办公室，我们有一个光纤连接。
- Gevent和BTC工人打得不好
- 我们已经切换到gunicorn同步工人和问题仍然存在。
- Gunicorn工作线程超时
- 工人可能以某种方式保持在空状态。
- 工人/动力不足
- 没有CPU/内存/数据库过度使用的迹象，New Relic没有显示任何数据库延迟的迹象
- 吵闹的邻居
- 在我与Heroku的多封电子邮件中，支持代表提到至少有一个我的长时间请求是由于一个吵闹的邻居，但不相信这是问题所在。
- 子域301
- 这些请求都很顺利，但在应用程序中随机卡住了。
- Dynos重启
- 如果是这样的话，很多用户都会受到影响。而且，我可以看到我们的dynos最近没有重新启动。
- Heroku路由/服务问题
- Heroku服务可能比广告宣传的要少，这只是使用他们服务的一个缺点。
我们在过去的几个月里一直有这个问题，但现在我们正在扩展它需要修复。任何想法将非常感谢因为我已经用尽了几乎每一个SO或谷歌链接。
2条答案
按热度按时间gblwokeq1#
在过去的6个月里，我一直与Heroku支持团队保持联系。这是一个很长的时间缩小通过试验/错误，但我们已经发现了问题。
我最终注意到这些高响应时间与突然的内存交换相对应，即使我正在为标准Dyno（没有空闲）付费，这些内存交换也是在我的应用程序最近没有收到流量时发生的。通过查看度量图表，还可以清楚地看到这不是内存泄漏，因为内存将趋于稳定。举例来说：
在与他们的支持团队进行了多次讨论后，我得到了这样的解释：
本质上，所发生的是一些后端运行时最终使用了运行时必须交换的足够内存的应用程序组合。当这种情况发生时，运行时上的一组随机dyno容器会被强制进行少量的任意交换（注意，这里的“随机”可能是内存最近没有被访问过但仍然驻留在内存中的容器）。与此同时，使用大量内存的应用程序最终也会大量交换，这会导致运行时的iowait比正常情况下更多。
自从这个问题变得越来越明显以来，我们根本没有改变我们对运行时的压缩程度，所以我们目前的假设是，这个问题可能来自于客户从2.1之前的Ruby版本转向2.1+。Ruby占了我们平台上运行的应用程序的很大一部分，Ruby 2.1对它的GC进行了更改，以内存使用换取速度（本质上，它不太频繁地GC以获得速度增益）。这会导致任何从旧版本Ruby迁移的应用程序的内存使用量显著增加。因此，之前保持一定内存使用水平的相同数量的Ruby应用程序现在开始需要更多的内存使用。
这种现象与平台上滥用资源的行为不端的应用程序相结合，达到了一个临界点，使我们看到了我们现在看到的不应该交换的dynos。我们正在研究一些攻击途径，但目前上述许多方法仍具有一定的推测性。我们确实知道其中一些是由滥用资源的应用程序引起的，这就是为什么迁移到Performance-M或Performance-L dynos（具有专用的后端运行时）不应该出现问题。这些dynos上的唯一内存使用将是您的应用程序的。所以，如果有swap，那是因为你的应用程序导致的。
我相信这是我和其他人一直在经历的问题，因为它与架构本身有关，而不是语言/框架/框架的任何组合。
除了A）坚韧起来等它出来或者B）切换到他们的专用示例之外，似乎没有什么好的解决方案
我知道有很多人说“这就是为什么你应该使用AWS”，但我发现Heroku提供的好处超过了偶尔的高响应时间，而且多年来它们的定价也变得更好。如果你也有同样的问题，“最好的解决方案”将是你的选择。我会更新这个答案，当我听到更多。
祝你好运！
6ljaweal2#
不确定这是否有帮助，但我现在正在Heroku上使用Rails应用程序经历同样的事情--看起来不确定的零星高请求时间。例如，
HEADNew Relic对我的网站索引的重定向通常需要2- 5 ms，耗时5秒，或者渲染我的网站登录，通常需要12秒。偶尔也会有30秒的超时。以下是Heroku的支持者在我的案例中所说的话（至少在某些情况下）：今天早些时候的一个看起来像是重启后的一大块请求处理。如果你想避免这些，你可能想看看我们的Preboot feature。这将允许您在部署后 Boot 一组匹配的dynos，然后将请求转交给它们，而不是跳过现有的dynos并强制请求同步。
我应该指出，这是Heroku的标准dyno重启之一，而不是我的部署或任何东西。尽管预引导页面上有警告，但我在几分钟前启用了它，所以我们将看看它是否对我的情况有任何影响。希望这可能会有所帮助，因为我一直在拉我的头发在这太！