La recarga del servidor de desarrollo Django lleva demasiado tiempo

Question

Este ha sido mi problema desde que me actualicé a OSX Lion: cada vez que el servidor de ejecución se recarga cuando cambio un archivo en mi proyecto Django, toma bastante tiempo antes de que vuelva a funcionar.

Esto ocurre incluso en un proyecto Django 1.4 recién creado. Aunque no tuve este problema en Snow Leopard.

que utilizan cprofile y aquí es donde se pasó la mayor parte de su tiempo:

Ordered by: cumulative time 

ncalls tottime percall cumtime percall filename:lineno(function) 
    1 0.001 0.001 48.068 48.068 manage.py:2(<module>) 
    1 0.000 0.000 48.033 48.033 __init__.py:431(execute_manager) 
    1 0.000 0.000 48.032 48.032 __init__.py:340(execute) 
    1 0.000 0.000 47.908 47.908 base.py:182(run_from_argv) 
    1 0.000 0.000 47.907 47.907 base.py:193(execute) 
    1 0.000 0.000 47.814 47.814 runserver.py:39(handle) 
    1 0.000 0.000 47.814 47.814 runserver.py:69(run) 
    1 0.001 0.001 47.814 47.814 autoreload.py:129(main) 
    1 0.000 0.000 47.813 47.813 autoreload.py:107(python_reloader) 
    1 0.000 0.000 47.813 47.813 autoreload.py:96(restart_with_reloader) 
    1 0.000 0.000 47.813 47.813 os.py:565(spawnve) 
    1 0.000 0.000 47.813 47.813 os.py:529(_spawnvef) 
    1 47.812 47.812 47.812 47.812 {posix.waitpid} 
    ... 

Pero no entiendo por qué?

Answer 1

La página de manual para waitpid dice: La llamada al sistema waitpid() suspende la ejecución del proceso de llamada hasta que un elemento especificado por el argumento pid ha cambiado de estado. De forma predeterminada, waitpid() solo espera para hijos finalizados, pero este comportamiento es modificable mediante el argumento opciones, como se describe a continuación. http://linux.die.net/man/2/waitpid

¿Por qué le toma tanto tiempo al proceso secundario cambiar de estado? El comando manage.py runserver Django es una envoltura muy fina sobre otro comando de ejecución del servidor:

2533 pts/0 Ss  0:00 \_ bash 
28374 pts/0 S+  0:00 | \_ ../env/bin/python ./manage.py runserver 
7968 pts/0 Sl+ 20:26 |  \_/home/sandford/workspace/usgm_apps/usgm_apps/../env/bin/python ./manage.py runserver 

Así que el "jefe" (28374) da cuenta de un cambio en un archivo y le dice al "trabajador" (7968) para salir. Una vez que el "trabajador" sale, se inicia un nuevo trabajador con los nuevos archivos fuente. El "trabajador" está tardando mucho en salir.

O OSX PIENSA que está tardando mucho en salir. Si el sistema operativo se retrasa en la contabilidad en el núcleo por alguna razón y demora la actualización del estado, podría terminar con un retraso como este.

O tal vez hay algo más que está pasando completamente. Es desconcertante.

Answer 2

(para chicos todavía googlear la respuesta)

tuve un problema similar con Vagrant (en la máquina host de Windows). La solución para mí fue mover la carpeta virtualenv lejos de sincronizado /vagrant. La configuración predeterminada de las carpetas sincronizadas usa el proveedor de VirtualBox y ese es el problema. Podemos leer sobre esto en otros métodos de sincronización de Vagrant official documentation:

En algunos casos las implementaciones carpeta predeterminada compartida (tales como carpetas compartidas de VirtualBox) tienen penas de alto rendimiento. Si ve un rendimiento inferior al ideal con las carpetas sincronizadas, NFS puede ofrecer una solución.

y

SMB está incorporado a las máquinas Windows y proporciona una alternativa de mayor rendimiento a algunos otros mecanismos, como VirtualBox carpetas compartidas.

Consulte Vagrant shared folders benchmark para obtener información adicional.