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开发服务器重新加载时间太长

回答

相关问题