Alta carga de CPU en el sitio Django / Apache / mod_wsgi


10

La prueba de carga de una configuración de django 1.21 / Apache / mod_wsgi en una instancia pequeña de AWS (Ubuntu 10.04) con el banco de Apache muestra una carga de CPU extremadamente alta (usando tiempo de actividad y vmstat) en solicitudes concurrentes bajas:

ab -c 5 -n 1000 "my_url"

... causa esta salida de tiempo de actividad:

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

La CPU está al 100% incluso con un valor de concurrencia de banco de Apache de 2. Estoy ejecutando el banco de Apache desde una instancia de AWS diferente en la misma región / zona. ¿Ideas sobre cuál es el problema o cómo debería continuar depurando esto?

Detalles:

  • Por desesperación, instalé un proyecto / aplicación vanjan django con una simple vista de "Hola mundo" (sin llamadas de DB, etc.). Los mismos resultados Así que dudo que sea mi código de aplicación.
  • El uso de la memoria se ve bien durante la prueba de carga.

Aquí hay una salida vmstat antes / durante / después de la prueba de carga:

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
  • Estoy ejecutando una versión previa de apache2 ya que también estoy ejecutando WordPress, que se basa en PHP. (PHP no funciona bien con la versión de trabajo de Apache)

Aquí está mi archivo de hosts virtuales:

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>

Aquí está mi archivo 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

Aquí está mi archivo 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")

Al presionar una URL de Django desde un navegador durante la prueba de carga, he confirmado cualitativamente que la alta carga de la CPU está afectando el rendimiento.

He leído que esto podría no ser importante, pero lo veo mucho en mis registros de errores:

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

Aquí están mis resultados de banco de Apache, en caso de que sea útil:

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)

Respuestas:


2

El problema era que había instalado el paquete apache2-mpm-itk en lugar de apache2-mpm-prefork. apache2-mpm-itk se deriva de apache2-mpm-prefork, pero por alguna razón, no funcionó bien cuando se usó con mod_wsgi.


Al usar ITK MPM y mod_wsgi, se recomienda usar el modo de demonio mod_wsgi y deshabilitar el uso del intérprete de Python en los procesos integrados. Si se utiliza el modo incrustado, está cargando su aplicación en cada solicitud al igual que CGI.
Graham Dumpleton
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.