Django विकास सर्वर रीलोड बहुत लंबा लगता है

Question

यह मेरी समस्या है क्योंकि मैंने ओएसएक्स शेर में अपग्रेड किया है: जब भी मैं अपने 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} 
    ... 

लेकिन मैं क्यों समझ में नहीं आता?

Answer 1

वेटपिड के लिए मैनपेज कहता है: प्रतीक्षापिड() सिस्टम कॉल कॉलिंग प्रक्रिया के निष्पादन को निलंबित कर देता है जब तक कि पिड तर्क द्वारा निर्दिष्ट बच्चे को राज्य नहीं बदला जाता है। डिफ़ॉल्ट रूप से, waitpid() केवल समाप्त बच्चों के लिए प्रतीक्षा करता है, लेकिन यह व्यवहार विकल्प तर्क के माध्यम से संशोधित है, जैसा कि नीचे वर्णित है। http://linux.die.net/man/2/waitpid

बच्चे की प्रक्रिया को बदलने के लिए इतना समय क्यों लग रहा है?

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 

तो "बॉस" (28,374) एक फ़ाइल पर एक परिवर्तन देखा और "कार्यकर्ता" बताता है (7968) बाहर निकलने के लिए: Django manage.py runserver आदेश एक और runserver आदेश पर एक बहुत पतली आवरण है। एक बार "कार्यकर्ता" निकल जाने के बाद, यह नई स्रोत फ़ाइलों के साथ एक नया कार्यकर्ता शुरू करता है। "कार्यकर्ता" को बाहर निकलने में काफी समय लग रहा है।

या ओएसएक्स सोचता है कि बाहर निकलने में काफी समय लग रहा है। यदि किसी कारण से कर्नेल में बहीखाता पर ओएस पीछे हो जाता है और राज्य को अपडेट करने में देरी हो जाती है तो आप इस तरह की देरी के साथ समाप्त हो सकते हैं।

या शायद कुछ और पूरी तरह से चल रहा है। यह परेशान है।

Answer 2

(लोग अभी भी इस सवाल का जवाब googling के लिए) मैं (Windows होस्ट मशीन पर) Vagrant का उपयोग कर समान समस्या थी। मेरे लिए समाधान virtualenv फ़ोल्डर को /vagrant से दूर स्थानांतरित किया गया था। सिंक किए गए फ़ोल्डर्स की डिफ़ॉल्ट सेटिंग्स वर्चुअलबॉक्स प्रदाता का उपयोग करती है और यह समस्या है। हम Vagrant official documentation से दूसरे समन्वयन विधियों में इस बारे में पढ़ सकते हैं:

कुछ मामलों डिफ़ॉल्ट साझा फ़ोल्डर कार्यान्वयन (जैसे VirtualBox के फ़ोल्डर साझा) उच्च प्रदर्शन दंड राशि में। यदि आप सिंक किए गए फ़ोल्डर्स के साथ आदर्श प्रदर्शन से कम देख रहे हैं, तो एनएफएस समाधान प्रदान कर सकता है।

और

एसएमबी Windows मशीनों के लिए निर्मित और कुछ अन्य तंत्र के लिए एक उच्च प्रदर्शन विकल्प जैसे VirtualBox के फ़ोल्डर साझा प्रदान करता है।

अतिरिक्त जानकारी के लिए Vagrant shared folders benchmark देखें।