18

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

しかし、私はなぜ理解していないのですか？

4

3 に答える 3

1

waitpid のマンページには次のように書かれています。デフォルトでは、waitpid() は終了した子のみを待機しますが、この動作はオプション引数を介して変更できます。これについては以下で説明します。 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 は、終了に時間がかかると考えています。OS がなんらかの理由でカーネルのブックキーピングに遅れをとり、状態の更新が遅れると、このような遅延が発生する可能性があります。

あるいは、まったく別のことが起こっているのかもしれません。困惑しています。

于 2012-12-05T17:49:40.713 に答える