Перезагрузка сервера Django занимает слишком много времени

Это была моя проблема, так как я обновился до OSX Lion: всякий раз, когда перезагрузка сервера перезагрузки при изменении файла в моем проекте Django, требуется довольно много времени, прежде чем он снова начнет работать.

Это происходит даже во вновь созданном проекте 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}
    ...

Но я не понимаю, почему?

Ответы

Ответ 1

(для парней по-прежнему поиск в Google)

У меня была аналогичная проблема с использованием Vagrant (на главной машине Windows). Решение для меня было перемещение папки virtualenv в сторону от синхронизированного /vagrant. Настройки по умолчанию для синхронизированных папок используют поставщика VirtualBox и эту проблему. Мы можем прочитать об этом в других методах синхронизации из Официальная документация Vagrant:

В некоторых случаях реализация общих папок по умолчанию (например, общие папки VirtualBox) имеет высокую производительность. Если вы видите менее идеальную производительность с синхронизированными папками, NFS может предложить решение.

и

SMB встроен в компьютеры Windows и обеспечивает более высокую производительность, альтернативу другим механизмам, таким как общие папки VirtualBox.

Подробнее см. Vagrant share folders для дополнительной информации.

Ответ 2

В manpage для waitpid говорится: Системный вызов waitpid() приостанавливает выполнение вызывающего процесса до тех пор, пока ребенок, указанный аргументом pid, не изменит состояние. По умолчанию waitpid() ждет только для завершенных дочерних элементов, но это поведение может быть изменено с помощью аргумента options, как описано ниже. http://linux.die.net/man/2/waitpid

Почему так долго требуется, чтобы дочерний процесс изменил состояние? Команда django manage.py runningerver является очень тонкой оболочкой над ANOTHER командой runerver:

 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 ДУМАЕТ, что требуется много времени для выхода. Если ОС по какой-то причине отстает от бухгалтерского учета в ядре и задерживает обновление состояния, вы можете получить такую ​​задержку.

Или, возможно, там что-то еще происходит. Это смущает.