Il server di sviluppo di Django si ricarica troppo a lungo

Question

Questo è stato il mio problema da quando ho aggiornato a OSX Lion: Ogni volta che il server esegue il ricaricamento quando cambio un file nel mio progetto Django, ci vuole un po 'di tempo prima che ricominci a servire.

Questo accade anche in un progetto Django 1.4 appena creato. Non ho avuto questo problema però su Snow Leopard.

Ho usato Cprofile e questo è dove ha trascorso la maggior parte del suo tempo:

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} 
    ... 

Ma io non capisco perché?

Answer 1

La pagina di manuale per waitpid dice: La chiamata di sistema waitpid() sospende l'esecuzione del processo chiamante fino a quando un figlio specificato dall'argomento pid ha cambiato stato. Per impostazione predefinita, waitpid() attende solo i bambini terminati, ma questo comportamento è modificabile tramite l'argomento opzioni, come descritto di seguito. http://linux.die.net/man/2/waitpid

Perché ci vuole così tanto tempo prima che il processo figlio cambi stato? Il comando django manage.py runserver è un wrapper molto sottile sopra un altro comando runserver:

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 

Così il "capo" (28374) si accorge di un cambiamento su un file e racconta la "lavoratore" (7968) per uscire. Una volta che il "worker" termina, avvia un nuovo worker con i nuovi file sorgente. Il "lavoratore" impiega molto tempo per uscire.

O OSX PENSA ci vuole molto tempo per uscire. Se il sistema operativo rimane indietro nella contabilità del kernel per qualche motivo e ritarda lo stato di aggiornamento si potrebbe finire con un ritardo come questo.

O forse c'è qualcos'altro in corso. È perplesso.

Answer 2

(per i ragazzi ancora googling la risposta)

Ho avuto problemi simili utilizzando Vagrant (sulla macchina host Windows). Soluzione per me era spostare la cartella virtualenv lontano dal sincronizzato /vagrant. Le impostazioni predefinite delle cartelle sincronizzate utilizzano il provider VirtualBox e questo è il problema. Si può leggere su questo in un altro metodi di sincronizzazione da Vagrant official documentation:

In alcuni casi le implementazioni delle cartelle predefinite condivise (come VirtualBox cartelle condivise) hanno sanzioni ad alte prestazioni. Se si notano prestazioni inferiori alle prestazioni ideali con le cartelle sincronizzate, NFS può offrire una soluzione.

e

SMB è incorporata per macchine Windows e fornisce una maggiore alternativo di performance ad alcuni altri meccanismi come VirtualBox cartelle condivise.

Vedere Vagrant shared folders benchmark per ulteriori informazioni.