18

自从我升级到 OSX Lion 以来，这一直是我的问题：每当我在 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}
    ...

但我不明白为什么？

4

3 回答 3

12

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

我在使用 Vagrant（在 Windows 主机上）时遇到了类似的问题。对我来说，解决方案是将virtualenv文件夹从 synced中移开/vagrant。同步文件夹的默认设置使用 VirtualBox 提供程序，这就是问题所在。我们可以在Vagrant 官方文档的另一个同步方法中了解这一点：

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

和

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

有关更多信息，请参阅Vagrant 共享文件夹基准。

于 2015-01-17T09:08:14.027 回答
1

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 认为退出需要很长时间。如果操作系统由于某种原因落后于内核中的簿记并延迟更新状态，您最终可能会出现这样的延迟。

或者也许还有其他完全在发生的事情。这很令人困惑。

于 2012-12-05T17:49:40.713 回答
0

就我而言，这是由文件中加载的DjangoWhiteNoise模块引起的wsgi.py。在我的开发环境中添加禁用模块的条件后，服务器重新加载时间大大减少。

于 2018-03-21T01:40:56.693 回答