python - 错误 R14(超出内存配额)在 New Relic 中不可见

Question

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

在本地分析 django 应用程序的内存我没有发现任何问题。我们已经安装了 New Relic，一切似乎都很好，除了一个奇怪的地方:

http://screencast.com/t/Uv1W3bjd

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

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

我们的一些请求确实需要一段时间，因为它们会向 echosign 发出 soap 请求，有时可能需要 6-10 秒才能响应。这是否会以某种方式阻塞并导致新的测力计旋转起来？

这是我的过程文件:

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

我相信我可能已经找到了问题。

基于 posts喜欢these我认为我应该在 9-10 个 gunicorn worker 附近的某个地方。我认为这是不正确的(或者至少，这是针对我的应用所做的工作而言的)。

我一直在运行 9 个 gunicorn worker，最后意识到这是 heroku 和 local 之间唯一真正的区别(就配置而言)。

根据gunicorn design document给 worker 的建议是这样的:

DO NOT scale the number of workers to the number of clients you expect to have. Gunicorn should only need 4-12 worker processes to handle hundreds or thousands of requests per second.

Gunicorn relies on the operating system to provide all of the load balancing when handling requests. Generally we recommend (2 x $num_cores) + 1 as the number of workers to start off with. While not overly scientific, the formula is based on the assumption that for a given core, one worker will be reading or writing from the socket while the other worker is processing a request.

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

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

HEROKU 应该在某个地方添加此信息!! 至少我应该能够top 进入我正在运行的 dyno 以查看发生了什么。本来可以节省我数小时和数天的时间。