错误R14 (超出内存配额)在新的遗物中不可见

Question

在Heroku上不断收到错误R14 (超出内存配额)。

在本地分析django应用程序上的内存，我没有看到任何问题。我们已经安装了New Relic，看起来一切都很好，除了一个奇怪的地方：

http://screencast.com/t/Uv1W3bjd

内存使用量在每个dyno上徘徊在15mb左右，但由于某些原因，“dynos running”很快就扩展到了10+。我不确定这有什么意义，因为我们目前只在web dyno上运行。

我们也在运行芹菜，而且看起来也很正常(大约15mb)。虽然它是可疑的，因为我相信我们在这个启动时就开始出现错误了。

我们的一些请求确实需要一段时间，就像它们向echosign发送soap请求一样，有时可能需要6-10秒来响应。这是不是以某种方式阻塞并导致新的dyno旋转？

下面是我的proc文件：

web: python manage.py collectstatic --noinput; python manage.py compress; newrelic-admin run-program python manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 9 -k gevent --max-requests 250
celeryd: newrelic-admin run-program python manage.py celeryd -E -B --loglevel=INFO

不过，主要问题是内存错误。

Answer 1

我想我可能找到问题所在了。

基于像these这样的posts，我想我应该有9-10个黑角兽工人。我认为这是不正确的(或者至少，这是针对我的应用程序所做的工作)。

我已经运行了9个gunicorn工作程序，最终意识到这是heroku和local之间唯一的真正区别(就配置而言)。

据gunicorn design document报道，对员工的建议是这样的：

不会将工作进程的数量扩展到您期望拥有的客户端数量。Gunicorn应该只需要4-12个工作进程来处理每秒数百或数千个请求。

Gunicorn依赖操作系统在处理请求时提供所有的负载平衡。通常，我们建议(2 x $num_cores) +1作为开始时的工作者数量。虽然不太科学，但该公式是基于这样的假设:对于给定的内核，一个工人将从套接字读取或写入，而另一个工人正在处理请求。

虽然有关于Heroku Dyno CPU能力的信息，但我现在读到每个dyno都运行在大约1/4的内核上。不是超级强大，但我想足够强大了。

让我的员工降低到3 (根据他们的粗略公式，这甚至是很高的)似乎已经解决了我的内存问题，至少现在是这样。当我想起来的时候，关于内存警告的有趣的事情是它永远不会上升。它达到了103%左右，然后就停留在那里，而如果它实际上是一个泄漏，它应该一直上升，直到被关闭。所以我的理论是，我的工作人员最终消耗的内存刚刚超过512mb。

HEROKU应该在某个地方添加这个信息！！，至少我应该能够top到我的运行dyno中，看看发生了什么。会帮我省下几个小时甚至几天。