这是我的问题,因为我升级到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}
...
Run Code Online (Sandbox Code Playgroud)
但我不明白为什么?
pro*_*oxy 12
(对于仍在谷歌搜索答案的人)
我使用Vagrant(在Windows主机上)有类似的问题.我的解决方案是移动virtualenv文件夹远离同步/vagrant.同步文件夹的默认设置使用VirtualBox提供程序,这就是问题所在.我们可以通过Vagrant官方文档中的另一种同步方法来了解这一点:
在某些情况下,默认的共享文件夹实现(例如VirtualBox共享文件夹)具有高性能损失.如果您发现同步文件夹的性能不佳,NFS可以提供解决方案.
和
SMB是Windows机器内置的,它提供了一些其他机制(如VirtualBox共享文件夹)的更高性能替代方案.
有关额外信息,请参阅Vagrant共享文件夹基准.
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
Run Code Online (Sandbox Code Playgroud)
因此,“老板”(28374)注意到文件发生变化,并告诉“工人”(7968)退出。一旦“worker”退出,它就会使用新的源文件启动一个新的worker。“工人”需要很长时间才能退出。
或者 OSX 认为退出需要很长时间。如果操作系统由于某种原因在内核中的簿记方面落后并延迟更新状态,则最终可能会出现这样的延迟。
或者也许还有其他事情正在发生。真令人费解。
| 归档时间: |
|
| 查看次数: |
3759 次 |
| 最近记录: |