장고 메모리 사용량 감소.

장고 메모리 사용량 감소. 낮게 매달린 과일?

---

시간이 지남에 따라 메모리 사용량이 증가하고 Django를 다시 시작하는 것은 사용자에게 친절하지 않습니다.

메모리 사용량을 프로파일 링하는 방법을 잘 모르겠지만 측정을 시작하는 방법에 대한 팁이 유용합니다.

큰 이득을 얻을 수있는 몇 가지 간단한 단계가 있다고 생각합니다. 'debug'가 'False'로 설정되어 있는지 확인하는 것은 분명 큰 문제입니다.

누구든지 다른 사람을 제안 할 수 있습니까? 트래픽이 적은 사이트에서 캐싱을 어느 정도 개선 할 수 있습니까?

이 경우 mod_python을 사용하여 Apache 2.x에서 실행 중입니다. 나는 mod_wsgi가 조금 더 낫다고 들었지만 이득이 중요하다는 것을 알지 못한다면이 단계에서 전환하는 것이 까다로울 것입니다.

편집 : 지금까지 팁 주셔서 감사합니다. 메모리 사용량을 발견하는 방법에 대한 제안이 있으십니까? 파이썬 메모리 프로파일 링에 대한 가이드가 있습니까?

또한 언급했듯이 mod_wsgi로 전환하기가 까다로울 수있는 몇 가지 사항이 있으므로 그 방향으로 나아 가기 전에 기대할 수있는 이익에 대해 알고 싶습니다.

편집 : Carl은 읽을 가치가있는 약간 더 자세한 답변을 여기에 게시했습니다 .Django 배포 : Apache의 오버 헤드 절단

편집 : Graham Dumpleton의 기사 는 MPM 및 mod_wsgi 관련 항목에서 찾은 최고입니다. 오히려 아무도 앱 자체의 메모리 사용 디버깅에 대한 정보를 제공 할 수 없다는 것에 실망했습니다.

최종 편집 : 글쎄, Webfaction과 함께 아파치 재 컴파일을 도울 수 있는지 알아보기 위해이 문제에 대해 논의했습니다.

"MPM Worker + mod_wsgi 설정으로 전환하면 많은 이점을 얻을 것이라고 생각하지 않습니다. 약 20MB를 절약 할 수있을 것으로 예상되지만 그 이상은 아닙니다."

그래서! 이것은 원래의 질문으로 돌아갑니다 (나는 여전히 더 현명한 사람이 아닙니다). 문제가 어디에 있는지 식별하는 방법은 무엇입니까? 테스트하지 않고 최적화 해야하는 곳을 확인하기 위해 최적화하지 않지만 파이썬 메모리 사용량을 측정하는 자습서는 거의 없으며 장고에만 국한되는 것은 아닙니다.

모두의 도움에 감사하지만이 질문은 아직 열려 있다고 생각합니다!

또 다른 최종 편집 ;-)

나는 django-users 목록에서 이것을 물었고 매우 유용한 답글을 얻었습니다.

솔직히 마지막 업데이트!

이것은 방금 릴리스되었습니다. 아직 최고의 솔루션이 될 수 : Pympler 프로파일 링 장고 개체의 크기와 메모리 사용

---

데이터에 대한 전역 참조를 유지하지 않아야합니다. 이것은 파이썬 가비지 수집기가 메모리를 해제하지 못하게합니다.

를 사용하지 마십시오 mod_python. 아파치 내부에 인터프리터를로드합니다. 아파치를 사용해야 할 경우 mod_wsgi대신 사용하십시오. 전환하기 까다 롭지 않습니다. 많이 쉽다. djangomod_wsgi 를 구성하는 것이 brain-dead보다 쉽습니다 mod_python.

요구 사항에서 아파치를 제거 할 수 있다면 메모리에 훨씬 좋습니다. spawning파이썬 웹 응용 프로그램을 실행하는 새로운 빠른 확장 가능한 방법 인 것 같습니다.

편집 : mod_wsgi로 전환하는 것이 얼마나 까다로운 지 알 수 없습니다 . 매우 쉬운 작업이어야합니다. 스위치 관련 문제에 대해 자세히 설명하십시오.

---

mod_wsgi에서 실행 중이고 WSGI와 호환되므로 아마도 생성되는 경우 Dozer 를 사용하여 메모리 사용량을 볼 수 있습니다 .

mod_wsgi 아래에서 WSGI 스크립트의 맨 아래에 이것을 추가하십시오.

from dozer import Dozer
application = Dozer(application)

그런 다음 http : // domain / _dozer / index 에서 브라우저를 가리키면 모든 메모리 할당 목록이 표시됩니다.

또한 mod_wsgi에 대한 지원 목소리를 추가하겠습니다. mod_python에 비해 성능과 메모리 사용면에서 차이가 있습니다. Graham Dumpleton의 mod_wsgi에 대한 지원은 활발한 개발 및 메일 링리스트에있는 사람들이 설치를 최적화 할 수 있도록 도와줍니다. curse.com의 David Cramer는 트래픽이 많은 사이트에서 mod_wsgi로 전환 한 후 CPU 및 메모리 사용량의 급격한 감소를 보여주는 차트를 게시했습니다 (안타깝게도 지금은 찾을 수없는 것 같습니다). 장고 개발자 중 일부가 전환했습니다. 진심으로, 그것은 쉬운 일이 아닙니다 :)

---

다음은 내가 알고있는 Python 메모리 프로파일 러 솔루션입니다 (Django와 관련이 없음).

• 히피
• 파이 사이 저 (단종)
• 파이썬 메모리 검사기 (상업용)
• 파이 머

면책 조항 : 나는 후자에 지분이 있습니다.

개별 프로젝트 문서는 이러한 도구를 사용하여 Python 응용 프로그램의 메모리 동작을 분석하는 방법에 대한 아이디어를 제공해야합니다.

다음은 유용한 "전쟁 이야기"로서 유용한 정보를 제공합니다.

• 파이썬 응용 프로그램의 설치 공간 감소

---

또한 알려진 누출 장치를 사용하지 않는지 확인하십시오. MySQLdb는 유니 코드 처리의 버그로 인해 Django에서 엄청난 양의 메모리를 유출하는 것으로 알려져 있습니다. 그 외에도 Django Debug Toolbar 는 호그를 추적하는 데 도움이 될 수 있습니다.

---

큰 데이터 개체에 대한 전역 참조를 유지하지 않고 가능한 한 큰 데이터 집합을 메모리에로드하지 마십시오.

데몬 모드에서 mod_wsgi로 전환하고 prefork 대신 Apache의 worker mpm을 사용하십시오. 후자의 단계를 통해 훨씬 적은 메모리 오버 헤드로 더 많은 동시 사용자에게 서비스를 제공 할 수 있습니다.

---

Webfaction에는 실제로 django 메모리 사용을 줄이는 팁 이 있습니다.

주요 포인트 :

• 디버그가 false로 설정되어 있는지 확인하십시오 (이미 알고 있음).
• 아파치 설정에서 "ServerLimit"사용
• 큰 객체가 메모리에로드되지 않았는지 확인
• 별도의 프로세스 또는 서버에서 정적 컨텐츠를 제공하십시오.
• 아파치 설정에서 "MaxRequestsPerChild"사용
• 사용중인 메모리 양을 확인하고 이해하십시오

---

Another plus for mod_wsgi: set a maximum-requests parameter in your WSGIDaemonProcess directive and mod_wsgi will restart the daemon process every so often. There should be no visible effect for the user, other than a slow page load the first time a fresh process is hit, as it'll be loading Django and your application code into memory.

But even if you do have memory leaks, that should keep the process size from getting too large, without having to interrupt service to your users.

---

Here is the script I use for mod_wsgi (called wsgi.py, and put in the root off my django project):

import os
import sys
import django.core.handlers.wsgi

from os import path

sys.stdout = open('/dev/null', 'a+')
sys.stderr = open('/dev/null', 'a+')

sys.path.append(path.join(path.dirname(__file__), '..'))

os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
application = django.core.handlers.wsgi.WSGIHandler()

Adjust myproject.settings and the path as needed. I redirect all output to /dev/null since mod_wsgi by default prevents printing. Use logging instead.

For apache:

<VirtualHost *>
   ServerName myhost.com

   ErrorLog /var/log/apache2/error-myhost.log
   CustomLog /var/log/apache2/access-myhost.log common

   DocumentRoot "/var/www"

   WSGIScriptAlias / /path/to/my/wsgi.py

</VirtualHost>

Hopefully this should at least help you set up mod_wsgi so you can see if it makes a difference.

---

Caches: make sure they're being flushed. Its easy for something to land in a cache, but never be GC'd because of the cache reference.

Swig'd code: Make sure any memory management is being done correctly, its really easy to miss these in python, especially with third party libraries

Monitoring: If you can, get data about memory usage and hits. Usually you'll see a correlation between a certain type of request and memory usage.

---

We stumbled over a bug in Django with big sitemaps (10.000 items). Seems Django is trying to load them all in memory when generating the sitemap: http://code.djangoproject.com/ticket/11572 - effectively kills the apache process when Google pays a visit to the site.

참고URL : https://stackoverflow.com/questions/487224/reducing-django-memory-usage-low-hanging-fruit