nginx 프록시를 사용하는 Apache+mod_wsgi의 Python Django 사이트: 성능 변동이 심함

nginx 프록시를 사용하는 Apache+mod_wsgi의 Python Django 사이트: 성능 변동이 심함

나는 mod_wsgi(임베디드 모드;더 빠른 모드, 올바르게 구성된 경우). 성능 변동폭이 큽니다. 때로는 빠르기도 하고, 때로는 몇 초 정도 지연되기도 합니다. 흡연 그래프가 여기저기에 있습니다.

최근에는 변동이 심한 성능을 해결하기 위해 정적 콘텐츠에 대한 nginx 프록시도 추가했습니다. 그러나 Apache가 처리해야 하는 요청 수를 크게 줄였음에도 불구하고 주요 문제에는 도움이 되지 않았습니다.

htop을 실행하는 동안 웹사이트를 클릭하면 요청이 거의 즉각적으로 이루어지는 경우도 있지만 때로는 Apache가 몇 초 동안 CPU를 100% 소모하는 경우도 있습니다. 이런 변동이 어디서 오는지 정말 이해가 되지 않습니다.

Apache용 mpm_worker를 다음과 같이 구성했습니다.

StartServers          1
MinSpareThreads      50
MaxSpareThreads      50
ThreadLimit          64
ThreadsPerChild      50
MaxClients           50
ServerLimit          1
MaxRequestsPerChild  0
MaxMemFree           2048

스레드가 50개 있는 서버 1대, 클라이언트 최대 50개. 무닌과 apache2ctl -t둘 다 일관적인 노동자의 존재감을 보여준다. 그들은 파괴되지 않고 항상 생성됩니다. 그러나 그것은 그렇게 행동합니다.

이것하위 인터프리터가 생성되면 메모리에 남아 있어야 하지만 사이트는 항상 다시 로드해야 하는 것 같습니다.

나는 또한 꽤 잘 작동하는 nginx+gunicorn 상자를 가지고 있습니다. Apache가 왜 그렇게 무작위인지 알고 싶습니다.

이것은 가상 호스트 구성입니다.

<VirtualHost *:81>
    ServerAdmin [email protected]
    ServerName example.com

    DocumentRoot /srv/http/site/bla

    Alias /static/ /srv/http/site/static
    Alias /media/ /srv/http/site/media
    WSGIScriptAlias / /srv/http/site/passenger_wsgi.py

    <Directory />
            AllowOverride None
    </Directory>

    <Directory /srv/http/site>
            Options -Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

  • 우분투 10.04
  • 아파치 2.2.14
  • mod_wsgi 2.8
  • nginx 0.7.65

편집: 로드될 때마다 tmp 파일에 날짜를 기록하는 사이트의 settings.py 파일에 일부 코드를 넣었습니다. 이제 사이트가 항상 무작위로 다시 로드되지는 않으므로 Apache가 해당 사이트를 메모리에 유지해야 한다는 것을 알 수 있습니다. 그래서 좋은 것 같습니다. 단, 답변에 더 가까워지지는 않는다는 점만 빼면...

편집: 방금 이것과 관련이 있을 수 있는 오류를 발견했습니다.

  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)

  File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
    self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

서버에는 2000MB 중 600MB의 여유 공간이 있으므로 충분합니다. Apache 또는 WSGI 어딘가에 제한이 설정되어 있습니까?

답변1

웹 애플리케이션에 문제가 있는지 확인하기 위해 New Relic을 사용해 보셨나요? 무료 등급이 제공되며 초기 전체 평가판도 제공됩니다. 이를 통해 얻을 수 있는 기능 개요:

사용되는 백엔드 서비스의 웹 애플리케이션과 관련된 특정 문제가 문제로 눈에 띄지 않는 경우 WSGI 서버 용량 분석 보고에 용량 부족 여부를 알려주는 내용이 표시될 수 있습니다. 또한 과잉 프로비저닝되어 리소스를 낭비하는지 여부도 알려줄 수 있는데, 이는 실제로 자주 발생하는 일입니다.

그런데 일반적으로 하나의 프로세스에서 50개의 요청 스레드를 사용하지 않는 것이 좋습니다. 약 5개의 스레드와 여러 프로세스를 사용하는 것이 더 좋습니다. 하지만 정확히 무엇이 가장 좋은지는 특정 애플리케이션, CPU 바인딩된 작업을 많이 수행하는지 여부, 장기 실행 요청을 처리해야 하는 정도에 따라 달라집니다. 동일한 Apache를 통해 많은 정적 파일을 제공하는지 여부도 영향을 미칠 수 있으며, mod_wsgi의 데몬 모드가 더 나은 전체 솔루션일 수도 있습니다.

또한 매우 오래된 mod_wsgi 버전을 사용하고 있지만 문제가 발생할 것이라고는 생각하지 않습니다.

마지막으로, Python용 일부 타사 C 확장 모듈과 관련된 문제를 방지하려면 이것이 해당 서버의 유일한 WSGI 애플리케이션인 경우 다음을 설정하십시오.

WSGIApplicationGroup %{GLOBAL}

답변2

나는 그것을 고쳤다. 데몬 모드에서 자체 프로세스를 사용하도록 모든 프로덕션 사이트를 변환했습니다(모든 개발 사이트도 모두 하나의 프로세스로 함께 사용). 이제 Smokeping 그래프가 훨씬 좋아졌습니다. 실적은 꾸준하다.

내가 말할 수 있는 한 프로세스 생성/파괴는 없었지만 적어도 더 나은 실행 서버를 갖고 있기 때문에 임베디드 모드에 이러한 문제가 발생한 이유에 대해 여전히 어둠에 빠져 있습니다.

편집하다:

Apache 사이트 구성의 예는 다음과 같습니다.

WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12

그런 다음 우선 순위가 낮은 사이트의 경우 다음을 입력했습니다 wsgi.conf.

WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}

그런 다음 Apache conf에서:

WSGIProcessGroup developmentsites

차이점을 살펴보세요(nginx 프록시로 인해):

여기에 이미지 설명을 입력하세요

관련 정보