Gunicorn: स्पष्ट करें कि क्या/कैसे टाइमआउट और ग्रेसफुल_टाइमआउट काम करते हैं

हम्म, मुझे लगता है कि https://github.com/benoitc/gunicorn/issues/1236#issuecomment -254059927 SIGTERM के बारे में मेरी धारणाओं की पुष्टि करता है अनुरोध प्रसंस्करण पूरा होने के बाद बस कार्यकर्ता को बंद करने के लिए सेट करना (और कार्यकर्ता को स्वीकार नहीं करने के लिए सेट करना) कोई नया कनेक्शन)।

ऐसा लगता है कि मैंने timeout की व्याख्या कैसे की और graceful_timeout गलत है। दोनों अवधि वास्तव में अनुरोध प्रसंस्करण की शुरुआत में समय को संदर्भित करती है। इसलिए, डिफ़ॉल्ट रूप से, क्योंकि दोनों सेटिंग्स 30 सेकंड पर सेट हैं, कोई भी शानदार पुनरारंभ सक्षम नहीं है। अगर मैं --graceful-timeout 15 --timeout 30 जैसा कुछ करता हूं, तो इसका मतलब यह होना चाहिए कि 15 सेकंड में ग्रेसफुल रीस्टार्ट शुरू हो जाता है और 30 सेकंड में वर्कर को मार दिया जाता है अगर अनुरोध इससे पहले पूरा नहीं हुआ।

हालांकि, ऐसा लगता है कि अगर प्रतिक्रिया graceful_timeout और timeout के बीच लौटा दी जाती है, तो कार्यकर्ता को फिर से शुरू नहीं किया जाता है? है ना?

मैंने app.py द्वारा परीक्षण किया:

import time
from flask import Flask

app = Flask(__name__)

@app.route('/foo')
def foo():
    time.sleep(3)
    return 'ok'

फिर:

12:51 $ gunicorn app:app --timeout 5 --graceful-timeout 1
[2017-04-03 12:51:37 +0300] [356] [INFO] Starting gunicorn 19.6.0
[2017-04-03 12:51:37 +0300] [356] [INFO] Listening at: http://127.0.0.1:8000 (356)
[2017-04-03 12:51:37 +0300] [356] [INFO] Using worker: sync
[2017-04-03 12:51:37 +0300] [359] [INFO] Booting worker with pid: 359

फिर मैं curl localhost:8000/foo भेजता हूं, जो 3 सेकंड के बाद वापस आता है। लेकिन गनिकोर्न में कुछ नहीं होता है - मुझे लगता है कि ग्रेसफुल रीस्टार्ट शुरू होने या होने का कोई निशान नहीं है?

ऐसा लगता है कि timeout पर, SystemExit(1,) फेंक दिया गया है, फ्लास्क में वर्तमान अनुरोध प्रसंस्करण को निरस्त कर दिया गया है। कौन सा कोड या सिग्नल इसे उत्पन्न करता है, यह नहीं कह सकता।

यह अपवाद फ्लास्क स्टैक के माध्यम से फेंका जाता है, और कोई भी teardown_request हैंडलर इसे पकड़ लेता है। कुछ लॉग करने के लिए पर्याप्त समय है, लेकिन यदि आप हैंडलर में time.sleep(1) या कुछ और समय लेते हैं, तो यह चुपचाप मारा जाता है। यह ऐसा है जैसे प्रक्रिया को वास्तव में बलपूर्वक समाप्त करने से पहले 100-200ms समय था और मैं सोच रहा हूं कि यह देरी क्या है। यह सुंदर समयबाह्य नहीं है, उस सेटिंग का विलंब पर कोई प्रभाव नहीं पड़ता है। मैं उम्मीद करता हूं कि स्टैक के माध्यम से SystemExit को फेंकने के बजाय प्रक्रिया को जबरदस्ती मार दिया जाएगा, लेकिन फिर संभावित रूप से प्रक्रिया को मध्य-हवा में मार दिया जाएगा।

वास्तव में, मुझे graceful_timeout कुछ भी करते हुए नहीं दिख रहा है - शायद यह सिंक श्रमिकों के लिए समर्थित नहीं है, या शायद यह "स्टैंड-अलोन" (या timeout के साथ) काम नहीं करता है - केवल जब आप मैन्युअल रूप से SIGTERM भेजते हैं?

इसके अलावा जो अजीब हो सकता है वह यह है कि https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L392 graceful ध्वज की बिल्कुल भी जांच नहीं करता है। मुझे लगता है कि https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L390 सुनिश्चित करता है कि self.WORKERS खाली है इसलिए गैर-सुंदर स्टॉप करते समय सुंदर टाइमआउट की प्रतीक्षा नहीं की जाती है।

@benoitc @tilgovi यहां हाथ देने की देखभाल? उम्मीद है कि ऊपर मेरे लेखन समझ में आता है ...

@ tuco86 graceful timeout केवल तभी उपलब्ध होता है जब आप मध्यस्थ से बाहर निकलते हैं, इसे अपग्रेड करते हैं (USR2), मध्यस्थ को एक HUP संकेत भेजते हैं या कार्यकर्ता को एक QUIT संकेत भेजते हैं। यानी इसका उपयोग केवल तब किया जाता है जब क्रिया सामान्य होती है

व्यस्त कर्मचारियों को अन्य अनुरोधों को अवरुद्ध करने से रोकने के लिए समयबाह्य यहाँ है। यदि वे timeout से कम समय में मध्यस्थ को सूचित नहीं करते हैं तो कार्यकर्ता बस बाहर निकल जाता है और ग्राहक के साथ कनेक्शन बंद हो जाता है।

उह, ठीक है। क्या timeout का कोई प्रभाव पड़ता है जब आप:

मध्यस्थ से बाहर निकलें, इसे अपग्रेड करें (USR2), मध्यस्थ को एक HUP संकेत भेजें या कार्यकर्ता को एक QUIT संकेत भेजें

मेरा मतलब है, क्या होगा यदि कार्यकर्ता graceful_timeout में शटडाउन नहीं करता है - उसके बाद timeout किक करेगा और श्रमिकों को बलपूर्वक मार दिया जाएगा, या यह उपयोगकर्ता के लिए SIGQUIT के लिए कॉल करने के लिए छोड़ दिया गया है

कार्यकर्ता को संकेत छोड़ो

मुझे लगता है कि आपका मतलब TERM था (जैसा कि QUIT को मास्टर और श्रमिकों दोनों के लिए _quick शटडाउन_ के रूप में प्रलेखित किया गया है)?

यदि कार्यकर्ता सुंदर समय के दौरान बंद नहीं करता है तो उसे बिना किसी देरी के मार दिया जाएगा।

बेशक। चीजों को स्पष्ट करने के लिए धन्यवाद!

@benoitc इस पुराने टिकट के संदर्भ में पूछना - timeout दस्तावेज़ीकरण में अंतिम वाक्य का वास्तव में क्या अर्थ है?

आम तौर पर तीस सेकंड के लिए सेट करें। इसे केवल तभी उच्च स्तर पर सेट करें जब आप सिंक कर्मचारियों के लिए नतीजों के बारे में सुनिश्चित हों। गैर-सिंक श्रमिकों के लिए इसका मतलब यह है कि कार्यकर्ता प्रक्रिया अभी भी संचार कर रही है और एक अनुरोध को संभालने के लिए आवश्यक समय की लंबाई से बंधी नहीं है।

एक देशी अंग्रेजी बोलने वाला नहीं होने के कारण, मुझे इसे समझने में मुश्किल होती है। क्या इसका मतलब यह है कि timeout गैर-सिंक श्रमिकों के लिए समर्थित नहीं है (क्योंकि मैं यही देख रहा हूं: मैं gthread श्रमिकों का उपयोग कर रहा हूं और टाइमआउट बहुत धीमी अनुरोधों को शुरू नहीं कर रहा है और मार रहा है )?

@tuukkamustonen --timeout अनुरोध टाइमआउट के रूप में नहीं है। यह श्रमिकों के लिए एक आजीविका जांच के रूप में है। सिंक कर्मचारियों के लिए, यह अनुरोध टाइमआउट के रूप में कार्य करता है क्योंकि कार्यकर्ता अनुरोध को संसाधित करने के अलावा कुछ भी नहीं कर सकता है। एसिंक्रोनस श्रमिक लंबे समय तक चलने वाले अनुरोधों को संभालने के दौरान भी दिल की धड़कन करते हैं, इसलिए जब तक कार्यकर्ता इसे ब्लॉक/फ्रीज नहीं करेगा तब तक इसे नहीं मारा जाएगा।

हो सकता है कि हमारे लिए नाम बदलना एक अच्छा विचार होगा यदि अन्य लोगों को यह भ्रमित करने वाला लगता है।

@tilgovi timeout ठीक है, हालांकि worker_timeout जैसा कुछ अधिक वर्णनात्मक हो सकता है। मैं अभी शुरू में भ्रमित हो गया क्योंकि timeout और graceful_timeout दस्तावेज़ीकरण में एक दूसरे के बगल में घोषित किए गए हैं, इसलिए मेरे दिमाग ने माना कि वे कसकर जुड़े हुए हैं, जबकि वे वास्तव में नहीं हैं।

सिंक कर्मचारियों के लिए, यह अनुरोध टाइमआउट के रूप में कार्य करता है क्योंकि कार्यकर्ता अनुरोध को संसाधित करने के अलावा कुछ भी नहीं कर सकता है। एसिंक्रोनस श्रमिक लंबे समय तक चलने वाले अनुरोधों को संभालने के दौरान भी दिल की धड़कन करते हैं, इसलिए जब तक कार्यकर्ता इसे ब्लॉक/फ्रीज नहीं करेगा तब तक इसे नहीं मारा जाएगा।

क्या आपके पास एक उदाहरण होगा जब timeout गैर-सिंक श्रमिकों के साथ शुरू होता है? क्या ऐसा कुछ है जो कभी नहीं होना चाहिए, वास्तव में - शायद केवल अगर कोई बग है जो कार्यकर्ता को अवरुद्ध/फ्रीज करने का कारण बनता है?

यह सही है। एक एसिंक्रोनस वर्कर जो एक इवेंट लूप कोर पर निर्भर करता है, एक सीपीयू गहन प्रक्रिया कर सकता है जो टाइमआउट के भीतर उत्पन्न नहीं होता है।

न केवल एक बग, दूसरे शब्दों में। हालांकि, कभी-कभी यह एक बग का संकेत दे सकता है, जैसे कि एक अवरुद्ध I/O फ़ंक्शन के लिए कॉल जब एक asyncio प्रोटोकॉल अधिक उपयुक्त होगा।

सीपीयू गहन कार्य में फंसना एक अच्छा उदाहरण है, धन्यवाद।

Async कोड में I/O को कॉल करना भी एक है, लेकिन मुझे यकीन नहीं है कि यह इस संदर्भ में कैसे लागू होता है - मैं ब्लॉकिंग कोड के साथ एक पारंपरिक फ्लास्क ऐप चला रहा हूं, लेकिन इसे एक एसिंक वर्कर के साथ चला रहा हूं ( gthread ) बिना किसी प्रकार के बंदर पैचिंग के। और यह ठीक काम करता है। मुझे पता है कि यह वास्तव में अब इस टिकट के संदर्भ में नहीं है, लेकिन इस तरह के एसिंक/सिंक कोड को मिश्रण और मिलान करने से समस्याएं नहीं आती हैं?

इसके अलावा, दिल की धड़कन का अंतराल क्या है? गैर-सिंक श्रमिकों के साथ timeout के लिए उपयोग करने के लिए एक समझदार मूल्य क्या होगा?

gthread कार्यकर्ता अतुल्यकालिक नहीं है, लेकिन इसमें दिल की धड़कन के लिए एक मुख्य धागा है, इसलिए यह टाइमआउट भी नहीं होगा। उस कार्यकर्ता के मामले में, आप शायद एक टाइमआउट नहीं देखेंगे जब तक कि कार्यकर्ता बहुत अधिक भारित न हो या अधिक संभावना है, आप एक सी एक्सटेंशन मॉड्यूल को कॉल करते हैं जो जीआईएल जारी नहीं करता है।

जब तक आप वर्कर टाइमआउट देखना शुरू नहीं करते हैं, तब तक आपको शायद टाइमआउट बदलने की जरूरत नहीं है।

ठीक है। बस एक और बात:

gthread कार्यकर्ता अतुल्यकालिक नहीं है

यह थोड़ा भ्रमित करने वाला हो सकता है कि gthread कार्यकर्ता async नहीं है, लेकिन http://docs.gunicorn.org/en/stable/design.html#asyncio -workers पर "AsyncIO" श्रमिकों के रूप में सूचीबद्ध है। इसके अलावा, "थ्रेड्स" का उपयोग करने के लिए एसिंक्सियो की आवश्यकता नहीं होती है, जिससे पाठक में भी सवाल उठते हैं। एक भोले-भाले उपयोगकर्ता के दृष्टिकोण से यह कहना, मुझे यकीन है कि यह सब तकनीकी रूप से अच्छी तरह से स्थापित है।

संक्षेप में, gthread कार्यकर्ता asyncio lib के साथ कार्यान्वित किया जाता है लेकिन यह सिंक कोड को संभालने के लिए धागे को जन्म देता है। अगर गलत हो तो मुझे सुधारो।

खुशी है कि आपने पूछा!

थ्रेडेड वर्कर asyncio का उपयोग नहीं करता है और बेस एसिंक्रोनस वर्कर क्लास से इनहेरिट नहीं करता है।

हमें दस्तावेज़ीकरण को स्पष्ट करना चाहिए। मुझे लगता है कि इसे एसिंक्स के रूप में सूचीबद्ध किया जा सकता है क्योंकि कार्यकर्ता टाइमआउट को समवर्ती रूप से संभाला जाता है, जिससे यह लंबे अनुरोधों और समवर्ती अनुरोधों को संभालने की क्षमता के संबंध में सिंक कार्यकर्ता की तुलना में एसिंक श्रमिकों की तरह व्यवहार करता है।

दस्तावेज़ीकरण को स्पष्ट करना और इसे सभी श्रमिकों का अधिक सटीक वर्णन करना बहुत अच्छा होगा।

हाँ gthreads कार्यकर्ता को asyncio कार्यकर्ता में सूचीबद्ध नहीं किया जाना चाहिए। हो सकता है कि प्रत्येक कर्मचारी के डिजाइन का वर्णन करने वाला एक खंड बेहतर हो?

इसे फिर से खोलना ताकि हम इसे वर्कर प्रकार और टाइमआउट पर अनुभाग को स्पष्ट करने के लिए कार्य के रूप में ट्रैक कर सकें।

@tilgovi

--टाइमआउट अनुरोध टाइमआउट के रूप में नहीं है। यह श्रमिकों के लिए एक आजीविका जांच के रूप में है। सिंक कर्मचारियों के लिए, यह अनुरोध टाइमआउट के रूप में कार्य करता है क्योंकि कार्यकर्ता अनुरोध को संसाधित करने के अलावा कुछ भी नहीं कर सकता है। एसिंक्रोनस श्रमिक लंबे समय तक चलने वाले अनुरोधों को संभालने के दौरान भी दिल की धड़कन करते हैं, इसलिए जब तक कार्यकर्ता इसे ब्लॉक/फ्रीज नहीं करेगा तब तक इसे नहीं मारा जाएगा।

क्या एसिंक्स वर्कर्स के लिए अनुरोध टाइमआउट विकल्प उपलब्ध है? दूसरे शब्दों में, एक निर्दिष्ट समय के भीतर अनुरोध को संसाधित नहीं करने वाले कार्यकर्ता को मध्यस्थ कैसे मार सकता है?

@aschatten दुर्भाग्य से नहीं है। #1658 भी देखें।

एक कार्यकर्ता को मार डालो जिसने एक निर्दिष्ट समय के भीतर अनुरोध को संसाधित नहीं किया

चूंकि एक कार्यकर्ता एक साथ कई अनुरोधों को संसाधित कर रहा है, पूरे कार्यकर्ता को मार रहा है क्योंकि एक अनुरोध का समय बहुत चरम लगता है। क्या इसके परिणामस्वरूप अन्य सभी अनुरोध व्यर्थ नहीं जाएंगे?

मुझे याद है कि यूडब्ल्यूएसजीआई 2.1 या तो में थ्रेड-आधारित हत्या शुरू करने की योजना बना रहा था, हालांकि शायद यह केवल सिंक/थ्रेडेड श्रमिकों के लिए भी लागू होता है (और इस पर मेरी याद अस्पष्ट है)।

चूंकि एक कार्यकर्ता एक साथ कई अनुरोधों को संसाधित कर रहा है, पूरे कार्यकर्ता को मार रहा है क्योंकि एक अनुरोध का समय बहुत चरम लगता है। क्या इसके परिणामस्वरूप अन्य सभी अनुरोध व्यर्थ नहीं जाएंगे?

दृष्टिकोण max_request के समान हो सकता है, जहां प्रत्येक कार्यकर्ता प्रकार के लिए एक अलग कार्यान्वयन होता है।

हम इस सप्ताह एक रिलीज पर काम कर रहे हैं, जिस बिंदु पर यह _may_ R20 के लिए शाखा करने का समय है, जहां हम कुछ प्रमुख चीजों से निपटने की योजना बना रहे हैं। प्रत्येक कार्यकर्ता प्रकार के लिए वर्तमान टाइमआउट को उचित अनुरोध टाइमआउट में बनाने का यह सही समय हो सकता है।

एक अलग मुद्दा दर्ज करने के बजाय यहां टिप्पणी करना क्योंकि मैं यह समझने की कोशिश कर रहा हूं कि टाइमआउट कैसे काम करना चाहिए और मुझे यकीन नहीं है कि यह एक बग है या नहीं।

मैं जो आईएमओ अप्रत्याशित व्यवहार देख रहा हूं वह यह है:

प्रत्येक अधिकतम-अनुरोध अनुरोध (जिसके बाद कार्यकर्ता को पुनरारंभ किया जाएगा) समय समाप्त हो गया है, जबकि अन्य अनुरोध सफलतापूर्वक पूर्ण हो गए हैं। नीचे दिए गए उदाहरण में 4 अनुरोध किए जाते हैं, अनुरोध 1, 2 और 4 सफल होते हैं, जबकि अनुरोध 3 विफल रहता है।

प्रासंगिक विन्यास:

• थ्रेड वर्कर
• सेवा अनुरोध समयबाह्य से अधिक समय लेता है
• अधिकतम-अनुरोध गैर-शून्य है

import time

def app(environ, start_response):
    start_response('200 OK', [('Content-type', 'text/plain; charset=utf-8')])
    time.sleep(5)
    return [b"Hello World\n"]

गनिकोर्न:

gunicorn --log-level debug -k gthread -t 4 --max-requests 3 "app:app"
...
[2018-02-08 10:11:59 +0200] [28592] [INFO] Starting gunicorn 19.7.1
[2018-02-08 10:11:59 +0200] [28592] [DEBUG] Arbiter booted
[2018-02-08 10:11:59 +0200] [28592] [INFO] Listening at: http://127.0.0.1:8000 (28592)
[2018-02-08 10:11:59 +0200] [28592] [INFO] Using worker: gthread
[2018-02-08 10:11:59 +0200] [28595] [INFO] Booting worker with pid: 28595
[2018-02-08 10:11:59 +0200] [28592] [DEBUG] 1 workers
[2018-02-08 10:12:06 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:11 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:15 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:20 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:23 +0200] [28595] [DEBUG] GET /
[2018-02-08 10:12:23 +0200] [28595] [INFO] Autorestarting worker after current request.
[2018-02-08 10:12:27 +0200] [28592] [CRITICAL] WORKER TIMEOUT (pid:28595)
[2018-02-08 10:12:27 +0200] [28595] [INFO] Worker exiting (pid: 28595)
[2018-02-08 10:12:28 +0200] [28595] [DEBUG] Closing connection.
[2018-02-08 10:12:28 +0200] [28599] [INFO] Booting worker with pid: 28599
[2018-02-08 10:12:32 +0200] [28599] [DEBUG] GET /
[2018-02-08 10:12:37 +0200] [28599] [DEBUG] Closing connection.
^C[2018-02-08 10:12:39 +0200] [28592] [INFO] Handling signal: int

ग्राहक:

[salonen<strong i="19">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World
[salonen<strong i="20">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World
[salonen<strong i="21">@mac</strong> ~]$ curl http://127.0.0.1:8000
curl: (52) Empty reply from server
[salonen<strong i="22">@mac</strong> ~]$ curl http://127.0.0.1:8000
Hello World

वहां क्या योजना होनी चाहिए? मेरे मन में निम्नलिखित है:

• [ ] कार्यकर्ता विवरण अपडेट करें (यदि अभी भी आवश्यक हो)
• [] मृत या अवरुद्ध श्रमिकों का पता लगाने के लिए प्रोटोकॉल का दस्तावेजीकरण करें

क्या यह 20.0 होना चाहिए या हम इसे स्थगित कर सकते हैं?

स्थगित करना

अरे, तो यह 20.0 का हिस्सा नहीं होगा?

प्रत्येक कार्यकर्ता प्रकार के लिए वर्तमान टाइमआउट को उचित अनुरोध टाइमआउट में बनाने का यह सही समय हो सकता है।

स्पष्ट किया। @ lucas03 यह स्पष्ट नहीं है कि अनुरोध टाइमआउट क्या है। अगर आपको कुछ खास चाहिए तो कृपया टिकट खोलें।