Bob*_*ryn 5 python django heroku
继续在Heroku上获得错误R14(超出内存配额).
在本地分析django应用程序的内存我没有看到任何问题.我们已经安装了New Relic,除了一个奇怪之外,似乎没什么好看的:
http://screencast.com/t/Uv1W3bjd
内存使用每个dyno徘徊在15mb左右,但由于某种原因,"dynos running"事物迅速扩展到10+.不确定这有什么意义,因为我们目前只在web dyno上运行.
我们也在经营芹菜,事情看起来也很正常(约15mb).虽然它是可疑的,因为我相信我们开始时会出现错误.
我们的一些请求确实需要一段时间,因为他们会向echosign发送肥皂请求,有时可能需要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
主要问题是内存错误.
Bob*_*ryn 14
我相信我可能已经找到了这个问题.
基于岗位像这些我想我应该有地方在9-10 gunicorn工人的区域.我认为这是不正确的(至少,它是我的应用程序正在做的工作).
我一直在运行9名枪手,终于意识到这是heroku和本地之间唯一真正的区别(就配置而言).
根据gunicorn设计文件,对工人的建议是这样的:
不要将工人数量扩大到您希望拥有的客户数量.Gunicorn应该只需要4-12个工作进程来处理每秒数百或数千个请求.
Gunicorn依赖操作系统在处理请求时提供所有负载平衡.通常我们建议(2 x $ num_cores)+ 1作为开始的工人数量.虽然不是过于科学,但公式是基于这样的假设:对于给定的核心,一个工作者将从套接字读取或写入而另一个工作者正在处理请求.
虽然有关于Heroku Dyno CPU能力的信息,我现在已经读到每个dyno运行在1/4 Core左右的东西上.不是超级强大,但我觉得足够强大.
把我的工人拨到3(根据他们粗略的公式甚至很高)似乎已经停止了我的记忆问题,至少目前如此.当我想到它时,我会得到的有关内存警告的有趣之处是它永远不会上升.它达到了103%左右,然后只是停留在那里,而如果它实际上是一个泄漏,它应该一直上升,直到被关闭.所以我的理论是我的工人最终消耗的内存足以超过512mb.
HEROKU应该添加这些信息!而且至少我应该能够top进入我正在运行的dyno以查看正在发生的事情.本来可以节省我数小时.
| 归档时间： |
|
| 查看次数： |
2184 次 |
| 最近记录： |