Hohe CPU-Auslastung auf der Django / Apache / mod_wsgi-Site


10

Beim Lasttest einer django 1.21 / Apache / mod_wsgi-Konfiguration auf einer kleinen AWS-Instanz (Ubuntu 10.04) mit Apache Bench wird bei niedrigen gleichzeitigen Anforderungen eine extrem hohe CPU-Auslastung (unter Verwendung von Uptime und vmstat) angezeigt:

ab -c 5 -n 1000 "my_url"

... verursacht diese Betriebszeitausgabe:

18:04:54 up 9 days, 16:54,  3 users,  load average: 5.33, 2.45, 1.91

Die CPU ist selbst bei einem Apache-Bench-Parallelitätswert von 2 zu 100% ausgelastet. Ich verwende Apache-Bench von einer anderen AWS-Instanz in derselben Region / Zone. Ideen, was das Problem ist oder wie ich das weiterhin debuggen soll?

Einzelheiten:

  • Aus Verzweiflung installierte ich ein Vanille-Django-Projekt / eine App mit einer einfachen "Hallo Welt" -Ansicht (keine DB-Aufrufe usw.). Gleiche Ergebnisse. Ich bezweifle, dass es mein Anwendungscode ist.
  • Die Speichernutzung sieht während des Auslastungstests gut aus.

Hier ist eine vmstat-Ausgabe vor / während / nach dem Auslastungstest:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
0  0      0 1034484  94848 321320    0    0     0     0   13   29  0  0 100  0
6  0      0 1032916  94848 321328    0    0     0     0  262  720  4 32 12  0
6  0      0 1031684  94848 321336    0    0     0     0  312  796  7 33  0  0
8  0      0 1030892  94856 321344    0    0     0    12  302  763  4 36  0  0
...
6  0      0 1030268  94864 321376    0    0     0     0  302  843  3 39  0  0
0  0      0 1032452  94868 321380    0    0     0    12  183  516  3 22 34  0
1  0      0 1033988  94868 321388    0    0     0     0   24   38  1  2 92  0
0  0      0 1033996  94868 321388    0    0     0     0   17   28  0  0 100  0
  • Ich verwende eine Prefork-Version von Apache2, da ich auch WordPress verwende, das auf PHP basiert. (PHP funktioniert nicht gut mit der Apache Worker-Version)

Hier ist meine virtuelle Hosts-Datei:

WSGIPythonHome /home/xxx/webapps/ve/api
<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName  app.xxx.mobi

        WSGIDaemonProcess snaplive user=www-data group=www-data processes=10 threads=1 maximum-requests=10000
        WSGIProcessGroup snaplive
        WSGIScriptAlias / /home/xxx/webapps/api/settings/apache/prod.wsgi
        DocumentRoot /home/xxx/webapps/api/static
        ErrorLog /var/log/apache2/django-live/error.log
        CustomLog /var/log/apache2/django-live/access.log combined
</VirtualHost>

Hier ist meine httpd.conf-Datei:

Alias /media /home/xxx/Django-1.2.1/django/contrib/admin/media
LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so

StartServers 2
MinSpareServers 2
MaxSpareServers 5
MaxClients 50
MaxRequestsPerChild 3000
ServerLimit 8
Keepalive off
HostnameLookups Off

Hier ist meine wsgi-Datei:

import os
import sys
sys.stdout = sys.stderr

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

sys.path.append("/home/xxx/webapps/api")

Durch das Aufrufen einer Django-URL in einem Browser während des Auslastungstests habe ich qualitativ bestätigt, dass die hohe CPU-Auslastung die Leistung beeinträchtigt.

Ich habe gelesen, dass dies möglicherweise nicht wichtig ist, aber ich sehe dies häufig in meinen Fehlerprotokollen:

[Sun Sep 19 18:04:58 2010] [error] Exception KeyError: KeyError(-1218693376,) in <module 'threading' from '/usr/lib/python2.6/threading.pyc'> ignored

Hier sind meine Apache-Bankergebnisse, falls hilfreich:

Server Software:        Apache/2.2.14
Server Hostname:        app.xxx.mobi
Server Port:            80

Document Path:          /plist_catalog/test_data
Document Length:        0 bytes

Concurrency Level:      5
Time taken for tests:   27.720 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      269000 bytes
HTML transferred:       0 bytes
Requests per second:    36.08 [#/sec] (mean)
Time per request:       138.598 [ms] (mean)
Time per request:       27.720 [ms] (mean, across all concurrent requests)
Transfer rate:          9.48 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   8.5      1      88
Processing:     9  136 176.9     81    1182
Waiting:        9  135 176.6     81    1182
Total:         10  138 176.7     83    1183

Percentage of the requests served within a certain time (ms)
  50%     83
  66%     98
  75%    128
  80%    140
  90%    423
  95%    576
  98%    727
  99%    819
 100%   1183 (longest request)

Antworten:


2

Das Problem war, dass ich das Paket apache2-mpm-itk anstelle von apache2-mpm-prefork installiert hatte. apache2-mpm-itk ist von apache2-mpm-prefork abgeleitet, hat aber aus irgendeinem Grund bei Verwendung mit mod_wsgi keine gute Leistung erbracht.


Bei Verwendung von ITK MPM und mod_wsgi wird empfohlen, den Dämonmodus mod_wsgi zu verwenden und die Verwendung von Python-Interpretern in eingebetteten Prozessen zu deaktivieren. Wenn der eingebettete Modus verwendet wird, laden Sie Ihre Anwendung bei jeder Anforderung genau wie CGI.
Graham Dumpleton
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.