Django開發服務器重新加載時間太長

自從我升級到OSX Lion以來，這一直是我的問題：當我在我的Django項目中更改文件時重新加載runserver時，它需要相當長的時間纔會開始再次服務。Django開發服務器重新加載時間太長

即使在新創建的Django 1.4項目中也會發生這種情況。雖然在雪豹上沒有這個問題。

我用CPROFILE，這是它花費了大部分時間：

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

但我不明白爲什麼？

來源

2012-07-11 Marconi

我遇到同樣的問題。你找到了解決方案嗎？ – fceruti 2012-10-30 03:28:52

@fceruti不，我沒有，直到有一天它消失了。不知道是否是我升級到OSX Mountain Lion的時候。 – Marconi 2012-11-24 10:02:46

我遇到同樣的問題。任何提示？ – 2017-05-25 11:35:10

waitpid的聯機幫助頁說： waitpid（）系統調用會暫停調用進程的執行，直到由pid參數指定的子級已更改狀態。默認情況下，waitpid（）僅等待終止的子節點，但此行爲可通過options參數進行修改，如下所述。 http://linux.die.net/man/2/waitpid

爲什麼兒童進程需要這麼長時間才能改變狀態？ Django的manage.py runserver命令命令是一個非常薄的包裝比另一個的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

所以「老闆」（28374）注意到在文件上的變化，並講述了「工人」（7968）退出。一旦「工作人員」退出，它將啓動一個新的工作人員並使用新的源文件。「工人」需要很長時間才能退出。

或OSX THINKS它需要很長時間才能退出。如果操作系統出於某種原因在內核中記賬，並延遲更新狀態，則最終可能會導致類似的延遲。

或者也許還有其他事情正在發生。這很令人困惑。

來源

2012-12-05 17:49:40

[來自Apple的waitpid manpage]（https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/waitpid.2。HTML），以防萬一有什麼細節不同，在這種情況下，我認爲不存在 – 2016-03-10 18:36:10

（對男人還是google搜索的答案）

我（在Windows主機）使用放浪類似的問題。對我來說，解決方案是將virtualenv文件夾從同步的/vagrant移開。同步文件夾的默認設置使用VirtualBox提供程序，這就是問題所在。我們可以用另一種方法同步從Vagrant official documentation讀到這樣的：

在某些情況下，默認共享文件夾的實現（如VirtualBox的共享文件夾）具有較高的性能損失。如果您看到同步文件夾的性能不理想，NFS可以提供解決方案。

和

SMB被內置在Windows機器並提供了更高的性能的替代一些其他機制，如VirtualBox的共享文件夾。

請參閱Vagrant shared folders benchmark瞭解更多信息。

來源

2015-01-17 09:08:14 proxy

你是一個完整的救生員。將我的virtualenv文件夾移出/ vagrant完全解決了我的速度問題，謝謝！ – Steadman 2017-05-24 19:10:49

Django開發服務器重新加載時間太長

回答

相關問題