Question

自从我升级到OSX Lion以来，这一直是我的问题：每当我在Django项目中更改文件时runserver重新加载，在它再次开始服务之前需要很长时间。

即使在新创建的Django 1.4项目中也会发生这种情况。在Snow Leopard上没有遇到这个问题。

我使用了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}
    ...

但我不明白为什么？

Answer 1

（对于仍在谷歌上搜索答案的人）

我使用Vagrant（在Windows主机上）有类似的问题。我的解决方案是移动virtualenv文件夹远离已同步的/vagrant。同步文件夹的默认设置使用VirtualBox提供程序，这就是问题所在。我们可以在Vagrant official documentation的其他同步方法中阅读此内容：

在某些情况下，默认的共享文件夹实现（例如VirtualBox共享文件夹）会有很高的性能损失。如果您发现同步文件夹的性能不佳，则NFS可以提供解决方案。

和

SMB是Windows机器内置的，并且提供了一些其他机制（如VirtualBox共享文件夹）的更高性能替代方案。

有关额外信息，请参阅Vagrant shared folders benchmark。

Answer 2

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）退出。一旦“worker”退出，它就会使用新的源文件启动一个新的worker。 “工人”需要很长时间才能退出。

或者OSX认为它需要很长时间才能退出。如果由于某种原因操作系统在内核中进行簿记并延迟更新状态，那么最终可能会出现这样的延迟。

或者也许还有其他事情发生了。这令人困惑。

Answer 3

在我的情况下，它是由wsgi.py文件中加载的DjangoWhiteNoise模块引起的。在我添加了在我的开发环境中禁用模块的条件后，服务器重新加载时间大幅减少。

Django开发服务器重新加载需要太长时间

3 个答案: