我在Digital Ocean服务器上运行Django应用程序(基于Django Rest Framework构建),具有以下特征:
我正在使用Gunicorn运行Django app和Celery来管理队列。数据库是MySQL。
我可以看到CPU使用率非常低,但内存使用量似乎很大。
部署之后,我注意到python3
进程使用的内存更多(约为75%)。每当我部署时,我都在运行after_deploy
脚本,其中包含以下内容:
service nginx restart
service gunicorn restart
chmod +x /mnt/myapplication/current/myapplication/setup/restart.sh
source /mnt/env/bin/activate
cd /mnt/myapplication/current/
pip3 install -r requirements.txt
python3 manage.py migrate --noinput >> /mnt/migrations/migrations.log
rm -f celerybeat.pid
rm -f celeryd.pid
celery -A myapplication beat -l info -f /var/log/celery/celery.log --detach
celery -A myapplication worker -l info -f /var/log/celery/celery.log --detach
这些数字是否可以预期?如果没有,我该如何调查出现了什么问题?
答案 0 :(得分:2)
Python进程倾向于保留已分配的内存,因此如果你的某个python进程为给定的操作(一个Django视图,一个芹菜任务......)分配了大量内存,它确实会保留它,只要它&#39跑步。
只要内存使用率保持稳定(我的意思是:在流程启动后增长到一定数量然后保持这个数量)并且您的服务器没有交换,通常没有什么可担心的,因为进程将继续重用已经分配的内存。
现在,如果您发现内存使用量一直在增长,那么您可能确实会在某处发生内存泄漏。
请注意,使用settings.DEBUG
运行芹菜 - 或django FWIW 会导致内存泄漏 - 但是你永远不应该在设置`settings.DEBUG标志的情况下运行你的生产过程,因为这是也是一个安全问题。
如果那不是你的情况,那么你可以开始在这里和网上的其他地方搜索"调试python内存泄漏"。您可能会找到一个很好的起点here:
Python应用程序泄漏内存并不容易。平时 有三种情况:
- 某些低级C库正在泄漏
- 您的Python代码包含随时间增长的全局列表或词组,并且您忘记在使用后删除对象
- 您的应用中有一些参考周期
和here:
尤其对于芹菜,您可以推动芹菜工作流程 经常。这正是CELERYD_MAX_TASKS_PER_CHILD设置的作用。