Charge CPU élevée sur le site Django / Apache / mod_wsgi


10

Le test de charge d'une configuration django 1.21 / Apache / mod_wsgi sur une petite instance AWS (Ubuntu 10.04) avec banc Apache montre une charge CPU extrêmement élevée (en utilisant uptime et vmstat) à de faibles demandes simultanées:

ab -c 5 -n 1000 "my_url"

... provoque cette sortie de disponibilité:

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

Le processeur est à 100% même avec une valeur de concurrence de banc Apache de 2. J'exécute le banc Apache à partir d'une instance AWS différente dans la même région / zone. Des idées sur quel est le problème, ou comment dois-je continuer à déboguer?

Détails:

  • Par désespoir, j'ai installé un projet / application django vanilla avec une simple vue "Hello World" (pas d'appels DB, etc.). Mêmes résultats. Je doute donc que ce soit mon code d'application.
  • L'utilisation de la mémoire semble correcte pendant le test de charge.

Voici une sortie vmstat avant / pendant / après le test de charge:

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
  • J'utilise une version préfork d'apache2 car j'utilise également WordPress, qui repose sur PHP. (PHP ne fonctionne pas bien avec la version de travail d'Apache)

Voici mon fichier d'hôtes virtuels:

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>

Voici mon fichier httpd.conf:

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

Voici mon fichier wsgi:

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")

En appuyant sur une URL django à partir d'un navigateur pendant le test de charge, j'ai confirmé qualitativement que la charge élevée du processeur affecte les performances.

J'ai lu que cela n'était peut-être pas important, mais je le constate souvent dans mes journaux d'erreurs:

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

Voici mes résultats de banc Apache, au cas où cela serait utile:

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)

Réponses:


2

Le problème était que j'avais installé le paquet apache2-mpm-itk au lieu d'apache2-mpm-prefork. apache2-mpm-itk est dérivé de apache2-mpm-prefork, mais pour une raison quelconque, ne fonctionnait pas bien lorsqu'il était utilisé avec mod_wsgi.


Lorsque vous utilisez ITK MPM et mod_wsgi, il est recommandé d'utiliser le mode démon mod_wsgi et de désactiver l'utilisation de l'interpréteur Python dans les processus intégrés. Si le mode intégré est utilisé, vous chargez votre application à chaque demande, tout comme CGI.
Graham Dumpleton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.