Elevato carico della CPU sul sito Django / Apache / mod_wsgi


10

Test di carico di una configurazione django 1.21 / Apache / mod_wsgi su una piccola istanza AWS (Ubuntu 10.04) con banco Apache mostra un carico della CPU estremamente elevato (utilizzando uptime e vmstat) a richieste concomitanti basse:

ab -c 5 -n 1000 "my_url"

... causa questo output di uptime:

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

La CPU è al 100% anche con un valore di concorrenza del banco Apache pari a 2. Sto eseguendo il banco Apache da un'altra istanza AWS nella stessa regione / zona. Idee su quale sia il problema o come dovrei continuare a eseguire il debug di questo?

Dettagli:

  • Per disperazione, ho installato un progetto / app vanilla django con una semplice vista "Hello World" (nessuna chiamata DB, ecc.). Stessi risultati Quindi dubito che sia il mio codice dell'applicazione.
  • L'utilizzo della memoria sembra corretto durante il test di caricamento.

Ecco un output vmstat prima / durante / dopo il test di carico:

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
  • Sto eseguendo una versione prefork di apache2 poiché sto anche eseguendo WordPress, che si basa su PHP. (PHP non funziona bene con la versione di lavoro di Apache)

Ecco il mio file di host virtuali:

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>

Ecco il mio file 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

Ecco il mio file 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")

Colpendo un URL django da un browser durante il test di carico, ho confermato qualitativamente che l'elevato carico della CPU influisce sulle prestazioni.

Ho letto che questo potrebbe non essere importante, ma lo vedo molto nei miei log degli errori:

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

Ecco i risultati della mia panca Apache, nel caso 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)

Risposte:


2

Il problema era che avevo installato il pacchetto apache2-mpm-itk invece di apache2-mpm-prefork. apache2-mpm-itk è derivato da apache2-mpm-prefork, ma per qualche ragione, non ha funzionato bene se usato con mod_wsgi.


Quando si utilizza ITK MPM e mod_wsgi, si consiglia di utilizzare la modalità demone mod_wsgi e disabilitare l'uso dell'interprete Python nei processi incorporati. Se si utilizza la modalità incorporata, si sta caricando l'applicazione su ogni richiesta, proprio come CGI.
Graham Dumpleton,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.