त्रुटि की उम्मीद नहीं है, लेकिन आपके उदाहरण से ऐसा कुछ भी नहीं है जो दिखाता है कि ऐसा क्यों होता है। हमें अपने पर्यावरण के बारे में और बताएं।

Gunicorn से कनेक्ट करने के लिए किस क्लाइंट का उपयोग किया जाता है?
Gunicorn से कनेक्ट करने के लिए क्या रिवर्स प्रॉक्सी, यदि कोई हो, का उपयोग किया जाता है?

tilgovi 5 जून 2018

हमें अपने पर्यावरण के बारे में और बताएं।

Gunicorn से कनेक्ट करने के लिए किस क्लाइंट का उपयोग किया जाता है?
=> मैं सिर्फ क्रोमियम से अनुरोध भेजता हूं: http://localhost :5000/
Gunicorn से कनेक्ट करने के लिए क्या रिवर्स प्रॉक्सी, यदि कोई हो, का उपयोग किया जाता है?
=> कोई प्रॉक्सी नहीं, बस Gunicorn + Flask

मैंने अभी पूरी तरह से नए सेटअप पर समस्या को पुन: प्रस्तुत किया है, यहां चरण दिए गए हैं:

mkdir gunicorn
cd gunicorn/
pipenv --python 3.6
pipenv install flask
pipenv install gunicorn
vim hello.py
pipenv shell
gunicorn -b 0.0.0.0:5000 --log-level=debug hello

hello.py बिल्कुल वैसा ही फ्लास्क एप्लिकेशन है जैसा मैंने प्रारंभिक रिपोर्ट में पोस्ट किया था।
नीचे पूरा लॉग है।

~$ gunicorn -b 0.0.0.0:5000 --log-level=debug hello
[2018-06-06 09:16:21 +0200] [19829] [DEBUG] Current configuration:
  config: None
  bind: ['0.0.0.0:5000']
  backlog: 2048
  workers: 1
  worker_class: sync
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /home/dima/work/gunicorn
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1000
  group: 985
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: None
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: -
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  statsd_prefix: 
  proc_name: None
  default_proc_name: hello
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f9757112d08>
  on_reload: <function OnReload.on_reload at 0x7f9757112e18>
  when_ready: <function WhenReady.when_ready at 0x7f9757112f28>
  pre_fork: <function Prefork.pre_fork at 0x7f9756c230d0>
  post_fork: <function Postfork.post_fork at 0x7f9756c231e0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f9756c232f0>
  worker_int: <function WorkerInt.worker_int at 0x7f9756c23400>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f9756c23510>
  pre_exec: <function PreExec.pre_exec at 0x7f9756c23620>
  pre_request: <function PreRequest.pre_request at 0x7f9756c23730>
  post_request: <function PostRequest.post_request at 0x7f9756c237b8>
  child_exit: <function ChildExit.child_exit at 0x7f9756c238c8>
  worker_exit: <function WorkerExit.worker_exit at 0x7f9756c239d8>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f9756c23ae8>
  on_exit: <function OnExit.on_exit at 0x7f9756c23bf8>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: TLSv1
  raw_paste_global_conf: []
[2018-06-06 09:16:21 +0200] [19829] [INFO] Starting gunicorn 19.8.1
[2018-06-06 09:16:21 +0200] [19829] [DEBUG] Arbiter booted
[2018-06-06 09:16:21 +0200] [19829] [INFO] Listening at: http://0.0.0.0:5000 (19829)
[2018-06-06 09:16:21 +0200] [19829] [INFO] Using worker: sync
[2018-06-06 09:16:21 +0200] [19832] [INFO] Booting worker with pid: 19832
[2018-06-06 09:16:22 +0200] [19829] [DEBUG] 1 workers
[2018-06-06 09:16:48 +0200] [19832] [DEBUG] GET /
[2018-06-06 09:17:19 +0200] [19829] [CRITICAL] WORKER TIMEOUT (pid:19832)
[2018-06-06 09:17:19 +0200] [19832] [INFO] Worker exiting (pid: 19832)
[2018-06-06 09:17:19 +0200] [19872] [INFO] Booting worker with pid: 19872
^C[2018-06-06 09:17:26 +0200] [19829] [INFO] Handling signal: int
[2018-06-06 09:17:26 +0200] [19872] [INFO] Worker exiting (pid: 19872)
[2018-06-06 09:17:26 +0200] [19829] [INFO] Shutting down: Master

~$ pip list
Package      Version
------------ -------
click        6.7    
Flask        1.0.2  
gunicorn     19.8.1 
itsdangerous 0.24   
Jinja2       2.10   
MarkupSafe   1.0    
pip          10.0.1 
setuptools   39.2.0 
Werkzeug     0.14.1 
wheel        0.31.1

bigunyak 6 जून 2018

@bigunyak मुझे लगता है कि यह डिफ़ॉल्ट टाइमआउट के कारण है, आपका कार्यकर्ता 30 के लिए चुप रहा है। http://docs.gunicorn.org/hi/stable/settings.html#timeout

अपने लॉग से,

[2018-06-05 14:57:16 +0200] [11232] [DEBUG] GET /
[2018-06-05 14:57:47 +0200] [11229] [CRITICAL] WORKER TIMEOUT (pid:11232)

[2018-06-06 09:16:48 +0200] [19832] [DEBUG] GET /
[2018-06-06 09:17:19 +0200] [19829] [CRITICAL] WORKER TIMEOUT (pid:19832)

yunstanford 8 जून 2018

👍5

मैं एक ही चीज़ देख रहा हूं: सिंक वर्कर के साथ कोई अनुरोध नहीं करने पर भी कर्मचारी टाइम आउट कर रहे हैं।
इस लिहाज से, महत्वपूर्ण स्तर का लॉग काफी भ्रमित करने वाला है।

कोशिश करें कि गीवेंट कार्यकर्ता इसे हल कर सके।

yunstanford 8 जून 2018

इस लिहाज से, महत्वपूर्ण स्तर का लॉग काफी भ्रमित करने वाला है।

बिल्कुल, यह मेरा मूल प्रश्न था: यदि यह अपेक्षित व्यवहार है तो गंभीर त्रुटि क्यों?
कुछ पृष्ठभूमि प्राप्त करना भी अच्छा होगा कि श्रमिकों को पुनरारंभ करने की आवश्यकता क्यों है, शायद इसे डिज़ाइन दस्तावेज़ में जोड़ा जा सकता है।

bigunyak 8 जून 2018

👍12

मैं इसे भी देख रहा हूं ( examples/test.py साथ gunicorn test:app -b localhost:9595 --log-level=debug --timeout=5 का उपयोग करके पुन: प्रस्तुत) और मैं मानता हूं कि महत्वपूर्ण स्तर थोड़ा भ्रमित करने वाला है। मैं ठीक हूं इसे डीबग स्तर में बदल दें। @benoitc @tilgovi आप क्या सोचते हैं?

berkerpeksag 8 जून 2018

मुझे लगता है कि जानकारी का स्तर थोड़ा बेहतर हो सकता है।

yunstanford 9 जून 2018

मेरे पास Win10 पर MSYS2 के साथ भी ऐसा ही था लेकिन अंत में हल हो सका।

inform() of ...\gunicorn\workers\workertmp.py, os.fchmod मूल रूप से उपयोग किया जाता है। लेकिन यह एमएसवाईएस में काम नहीं करता है। os.fchmod के बजाय, मैंने os.utime का उपयोग किया। कोड का पालन किया जाता है। मुझे लगता है कि यह सभी प्लेटफॉर्म के लिए काम कर सकता है।

    def notify(self):
        try:
            self.spinner = (self.spinner + 1) % 2
            os.fchmod(self._tmp.fileno(), self.spinner)
            if PLATFORM.startswith('MSYS') :
                os.utime(self._tmp.fileno(), None)
        except AttributeError:
            # python < 2.6
            self._tmp.truncate(0)
            os.write(self._tmp.fileno(), b"X")

neocolor 14 जून 2018

@berkerpeksag मैं उम्मीद नहीं करता कि कार्यकर्ता बाहर निकलें क्योंकि कोई अनुरोध नहीं होता है। यह त्रुटि केवल तभी होनी चाहिए जब कार्यकर्ता को एक समय के लिए > टाइमआउट में व्यस्त रखा गया हो। इसलिए त्रुटि गंभीर है। आईएमओ हमें इस तरह की त्रुटियों के लिए अधिक उपयोग के मामलों और प्रतिक्रियाओं को प्रदान करने के लिए दस्तावेज़ीकरण में सुधार करना चाहिए।

यदि त्रुटि तब भी होती है जब कार्यकर्ता को व्यस्त नहीं रखा जाता है तो कुछ और हो रहा है और हमारे पास शायद एक बग है।

benoitc 20 जून 2018

👍12

[संपादित करें]
मेरे लिए वही बग।
Django 1.10/gunicorn 19.6.0/पायथन 2.7.15 के साथ python2.7-alpine में डेबियन 8.8 और स्टॉक कर्नेल 3.16 पर, सभी ठीक काम कर रहे थे।
Django 1.11 और gunicorn 19.8.1 को अपडेट करने के बाद, कार्यकर्ता [क्रिटिकल वर्कर टाइमआउट] के साथ बूट में विफल होते रहते हैं।
गनिकोर्न को 19.6.0 पर डाउनग्रेड करने से समस्या ठीक नहीं होती है।
हमने होस्ट कर्नेल को 4.9.0 में अपडेट किया (यह शेड्यूल किया गया था), और श्रमिकों ने त्रुटियों के बिना सफलतापूर्वक बूट किया।
लेकिन:

हम 4 श्रमिकों का उपयोग करते हैं
Django ऐप को ठीक 4 कॉल के बाद, अगली कॉल टाइमआउट हो जाएगी, लॉग में [क्रिटिकल वर्कर टाइमआउट] दिखा रही है
linux top कमांड 4 गनिकोर्न प्रक्रियाओं को दिखाता है जो बहुत अधिक CPU खपत के साथ अटकी हुई हैं।

हम यह देखने के लिए गनिकोर्न जीवेंट की कोशिश करने जा रहे हैं कि क्या हम अपने ऐप को ऑनलाइन वापस लाने में सक्षम हैं।

kozlek 6 जुल॰ 2018

गीवेंट के साथ गनिकोर्न का उपयोग करने से बग ठीक नहीं हुआ।

kozlek 6 जुल॰ 2018

👍37

इस मुद्दे पर कोई अपडेट?

baeriswyld 2 अग॰ 2018

👍10

ऐसा लगता है कि @neocolor ने MSYS के तहत एक वास्तविक बग की पहचान की है। यह एक अलग मुद्दे के लायक हो सकता है।

@bigunyak आप किस प्लेटफॉर्म पर चल रहे हैं? मैंने सरल उदाहरण के साथ पुन: पेश करने की कोशिश की है और मैं इसे ऊपर उल्लिखित चरणों का पालन नहीं कर सकता। यह मेरे अनुभव से कई ढांचे पर उत्पादन में कई अनुप्रयोगों को चलाने के साथ सहमत है। मेरी जानकारी में हाल ही में कार्यकर्ता अधिसूचना प्रणाली नहीं बदली है। मैकोज़ 10.13.6 पर मेरा मंच पायथन 3.7 है, लेकिन मैं पाइथन 2.7 और 3.6.5 पर कई अनुप्रयोगों के लिए सिंक श्रमिकों के साथ उत्पादन में गनिकोर्न चलाता हूं और केवल कार्यकर्ता टाइमआउट देखता हूं जब श्रमिकों को अवरुद्ध करने वाले वैध रूप से लंबे अनुरोध होते हैं।

@Tberdy के लिए : क्या होता है यदि आप --worker-tmp-dir को tmpfs फाइल सिस्टम के बाहर कहीं पर सेट करने का प्रयास करते हैं? मैं बस सोच रहा हूं कि शायद अल्पाइन या डॉकटर या संयोजन किसी तरह से हस्तक्षेप करता है कि कैसे कार्यकर्ता मध्यस्थ को सूचित करते हैं।

tilgovi 3 अग॰ 2018

डॉकर से संबंधित tmpfs मुद्दों के लिए #1388 भी देखें।

tilgovi 3 अग॰ 2018

मेरे पास यह मुद्दा है।

timoj58 7 अग॰ 2018

👍10

मेरे पास यह मुद्दा भी है, गनिकोर्न सिंक कल रात तक पूरी तरह से अच्छी तरह से काम कर रहा था, यूटी ने रिपोर्ट करना शुरू कर दिया, वर्कर्स टाइमआउट [क्रिटिकल] जेवेंट का उपयोग करके मेरी समस्या का समाधान हो रहा है, लेकिन मैं वास्तव में जानना चाहता हूं कि ऐसा क्यों हुआ।

cjmash 9 अग॰ 2018

👍1

@ timoj58 @cjmash आप मुद्दे के बारे में और अधिक विस्तार प्रदान करता है सकते हैं? आप गनिकोर्न कैसे चला रहे हैं (एक वीएम में?, विकल्प ...), कौन सा फाइल सिस्टम, ओएस? कुछ भी जो पुन: पेश करने में मदद कर सकता है वह बहुत उपयोगी होगा :)

benoitc 10 अग॰ 2018

@benoitc मैं कुबेरनेट्स पर अपना Django प्रोजेक्ट शुरू करने के लिए गनिकोर्न चला रहा हूं, मेरे गनिकोर्न तर्क हैं --bind=$port --workers=7 --timeout=1200 --log-level=debug --access-logfile - error-logfile - "

लॉग से मुझे जो त्रुटियां मिलती हैं

`` `ई [2018-08-09 21:47:56 +0000] [13] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 13

ई [2018-08-09 21:47:56 +0000] [14] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 14

ई [2018-08-09 21:47:56 +0000] [12] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 12

ई [2018-08-09 21:47:56 +0000] [1] [डीबग] 7 कर्मचारी

ई [2018-08-09 21:47:56 +0000] [11] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 11

ई [2018-08-09 21:47:55 +0000] [10] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 10

ई [2018-08-09 21:47:55 +0000] [9] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 9

ई [2018-08-09 21:47:55 +0000] [8] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 8

ई [2018-08-09 21:47:55 +0000] [1] [सूचना] कार्यकर्ता का उपयोग करना: सिंक

ई [2018-08-09 21:47:55 +0000] [1] [सूचना] यहां सुन रहा है: http://0.0.0.0 :4040 (1)

ई [2018-08-09 21:47:55 +0000] [1] [डीबग] आर्बिटर बूट हुआ

ई [2018-08-09 21:47:55 +0000] [1] [जानकारी] गनिकोर्न 19.7.1 शुरू

ई रॉ_पेस्ट_ग्लोबल_कॉन्फ: []

ई सिफर: TLSv1

ई do_handshake_on_connect: झूठा

ई सप्रेस_रैग्ड_ईओफ़्स: सच

ई ca_certs: कोई नहीं

ई सर्टिफिकेट_रेक: 0

ई एसएसएल_संस्करण: 2

ई सर्टिफिकेट: कोई नहीं

ई कीफाइल: कोई नहीं

ई प्रॉक्सी_आलो_आईपी: ['127.0.0.1']

ई प्रॉक्सी_प्रोटोकॉल: गलत

ई ऑन_एग्जिट:

ई nworkers_changed:

ई कार्यकर्ता_बाहर निकलें:

ई चाइल्ड_एग्जिट:

ई पोस्ट_अनुरोध:

ई पूर्व_अनुरोध:

ई pre_exec:

ई वर्कर_एबॉर्ट:

ई कार्यकर्ता_इंट:

ई पोस्ट_वर्कर_इनिट:

ई पोस्ट_फोर्क:

ई प्री_फोर्क:

ई जब_रेडी:

ई ऑन_रीलोड:

ई ऑन_स्टार्टिंग:

ई पेस्ट: कोई नहीं

ई पायथनपथ: कोई नहीं

ई default_proc_name: art.wsgi

ई proc_name: कोई नहीं

ई statsd_prefix:

ई statsd_host: कोई नहीं

ई enable_stdio_inheritance: गलत

ई syslog_facility: उपयोगकर्ता

ई syslog_prefix: कोई नहीं

ई सिसलॉग: झूठा

ई syslog_addr: udp://localhost :514

ई लॉगकॉन्फिग: कोई नहीं

ई लॉगर_क्लास: gunicorn.glogging.Logger

ई कैप्चर_आउटपुट: गलत

ई लॉगलेवल: डिबग

ई त्रुटि लॉग: -

ई access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%( जैसा"

ई एक्सेसलॉग:-

ई अग्रेषित_अनुमति_ips: ['127.0.0.1']

ई Secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}

ई tmp_upload_dir: कोई नहीं

ई इनिटग्रुप्स: असत्य

ई उमास्क: 0

ई समूह: 0

ई उपयोगकर्ता: 0

ई कार्यकर्ता_tmp_dir: कोई नहीं

ई पिडफाइल: कोई नहीं

ई रॉ_एनवी: []

ई डेमन: झूठा

ई chdir: /usr/src/app

ई सेंडफाइल: कोई नहीं

ई प्रीलोड_ऐप: गलत

ई check_config: गलत

ई स्पू: झूठा

ई रीलोड_इंजिन: ऑटो

ई पुनः लोड: गलत

ई लिमिट_रेक्वेस्ट_फील्ड_साइज: 8190

ई सीमा_अनुरोध_फ़ील्ड: 100

ई लिमिट_रेक्वेस्ट_लाइन: 4094

ई रखवाले: 2

ई ग्रेसफुल_टाइमआउट: 30

ई टाइमआउट: 1200

ई max_requests_jitter: 0

ई अधिकतम_अनुरोध: 0

ई कार्यकर्ता_कनेक्शन: 1000

ई धागे: 1

ई वर्कर_क्लास: सिंक

ई कार्यकर्ता: 7

ई बैकलॉग: 2048

ई बाइंड: ['0.0.0.0:4040']

ई विन्यास: कोई नहीं

ई [2018-08-09 21:47:55 +0000] [1] [डीबग] वर्तमान विन्यास:

I आवेदन करने के लिए कोई माइग्रेशन नहीं।

मैं माइग्रेशन चला रहा हूं:

मैं सभी माइग्रेशन लागू करता हूं: व्यवस्थापक, प्रमाणन, सामग्री प्रकार, कोर, डैशबोर्ड, जेट, oauth2_provider, सत्र

I संचालन करने के लिए:

ई [2018-08-09 21:47:20 +0000] [13] [सूचना] बाहर निकलने वाला कार्यकर्ता (पीआईडी: 13)

ई os.path.dirname(os.path.dirname(__file__)), '.env'))

ई /usr/src/app/art/wsgi.py:19: UserWarning: नहीं पढ़ रहा /usr/src/app/.env - यह अस्तित्व में नहीं है।

ई [2018-08-09 21:47:00 +0000] [21] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 21

ई [2018-08-09 21:47:00 +0000] [1] [सूचना] हैंडलिंग सिग्नल: टर्म

ई [2018-08-09 21:46:35 +0000] [12] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 12

ई [2018-08-09 21:46:34 +0000] [13] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 13

ई [2018-08-09 21:46:34 +0000] [11] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 11

ई [2018-08-09 21:46:34 +0000] [1] [डीबग] 7 कर्मचारी

ई [2018-08-09 21:46:34 +0000] [10] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 10

ई [2018-08-09 21:46:34 +0000] [9] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 9

ई [2018-08-09 21:46:34 +0000] [8] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 8

ई [2018-08-09 21:46:34 +0000] [7] [जानकारी] पीआईडी के साथ बूटिंग कार्यकर्ता: 7

ई [2018-08-09 21:46:34 +0000] [1] [सूचना] कार्यकर्ता का उपयोग करना: सिंक

ई [2018-08-09 21:46:34 +0000] [1] [सूचना] यहां सुन रहा है: http://0.0.0.0 :4040 (1)

ई [2018-08-09 21:46:34 +0000] [1] [डीबग] आर्बिटर बूट हुआ

ई [2018-08-09 21:46:34 +0000] [1] [सूचना] गनिकोर्न 19.7.1 शुरू करना

ई रॉ_पेस्ट_ग्लोबल_कॉन्फ: []

ई सिफर: TLSv1

ई do_handshake_on_connect: झूठा

ई सप्रेस_रैग्ड_ईओफ़्स: सच

ई ca_certs: कोई नहीं

ई सर्टिफिकेट_रेक: 0

ई एसएसएल_संस्करण: 2

ई सर्टिफिकेट: कोई नहीं

ई कीफाइल: कोई नहीं

ई प्रॉक्सी_आलो_आईपी: ['127.0.0.1']

ई प्रॉक्सी_प्रोटोकॉल: गलत

ई ऑन_एग्जिट:

ई nworkers_changed:

ई कार्यकर्ता_बाहर निकलें:

ई चाइल्ड_एग्जिट:

ई पोस्ट_अनुरोध:

ई पूर्व_अनुरोध:

ई pre_exec:

ई वर्कर_एबॉर्ट:

ई कार्यकर्ता_इंट:

ई पोस्ट_वर्कर_इनिट:

ई पोस्ट_फोर्क:

ई प्री_फोर्क:

ई जब_रेडी:

ई ऑन_रीलोड:

ई ऑन_स्टार्टिंग:

ई पेस्ट: कोई नहीं

ई पायथनपथ: कोई नहीं

ई default_proc_name: art.wsgi

ई proc_name: कोई नहीं

ई statsd_prefix:

ई statsd_host: कोई नहीं

ई enable_stdio_inheritance: गलत

ई syslog_facility: उपयोगकर्ता

ई syslog_prefix: कोई नहीं

ई सिसलॉग: झूठा

ई syslog_addr: udp://localhost :514

ई लॉगकॉन्फिग: कोई नहीं

ई लॉगर_क्लास: gunicorn.glogging.Logger

ई कैप्चर_आउटपुट: गलत

ई लॉगलेवल: डिबग

ई त्रुटि लॉग: -

ई access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%( जैसा"

ई एक्सेसलॉग:-

ई अग्रेषित_अनुमति_ips: ['127.0.0.1']

ई Secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}

ई tmp_upload_dir: कोई नहीं

ई इनिटग्रुप्स: असत्य

ई उमास्क: 0

ई समूह: 0

ई उपयोगकर्ता: 0

ई कार्यकर्ता_tmp_dir: कोई नहीं

ई पिडफाइल: कोई नहीं

ई रॉ_एनवी: []

ई डेमन: झूठा

ई chdir: /usr/src/app

ई सेंडफाइल: कोई नहीं

ई प्रीलोड_ऐप: गलत

ई check_config: गलत

ई स्पू: झूठा

ई रीलोड_इंजिन: ऑटो

ई पुनः लोड: गलत

ई लिमिट_रेक्वेस्ट_फील्ड_साइज: 8190

ई सीमा_अनुरोध_फ़ील्ड: 100

ई लिमिट_रेक्वेस्ट_लाइन: 4094

ई रखवाले: 2

ई ग्रेसफुल_टाइमआउट: 30

ई टाइमआउट: 1200

ई max_requests_jitter: 0

ई अधिकतम_अनुरोध: 0

ई कार्यकर्ता_कनेक्शन: 1000

ई धागे: 1

ई वर्कर_क्लास: सिंक

ई कार्यकर्ता: 7

ई बैकलॉग: 2048

ई बाइंड: ['0.0.0.0:4040']

ई विन्यास: कोई नहीं

ई [2018-08-09 21:46:34 +0000] [1] [डीबग] वर्तमान विन्यास:

```

cjmash 10 अग॰ 2018

मैंने इस बार समस्या को पुन: पेश करने के लिए थोड़ा संघर्ष किया लेकिन यह अभी भी नवीनतम गनिकोर्न संस्करण 19.9.0 में है।
इसे पुन: पेश करने के चरण ठीक उसी तरह हैं जैसे मैंने इस पोस्ट में वर्णित किया है।
मेरा सिस्टम आर्क लिनक्स x86_64 जीएनयू/लिनक्स (कर्नेल 4.17.2-1-एआरसीएच), पायथन 3.6.5 है
यहाँ एक ताज़ा लॉग ट्रेस है।

~$ gunicorn -b 0.0.0.0:5000 --log-level=debug hello
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] Current configuration:
  config: None
  bind: ['0.0.0.0:5000']
  backlog: 2048
  workers: 1
  worker_class: sync
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /home/dima/lerning/python/modules/gunicorn
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1000
  group: 985
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: None
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: -
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  statsd_prefix: 
  proc_name: None
  default_proc_name: hello
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f5f8b9dad08>
  on_reload: <function OnReload.on_reload at 0x7f5f8b9dae18>
  when_ready: <function WhenReady.when_ready at 0x7f5f8b9daf28>
  pre_fork: <function Prefork.pre_fork at 0x7f5f8b4ec0d0>
  post_fork: <function Postfork.post_fork at 0x7f5f8b4ec1e0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f5f8b4ec2f0>
  worker_int: <function WorkerInt.worker_int at 0x7f5f8b4ec400>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f5f8b4ec510>
  pre_exec: <function PreExec.pre_exec at 0x7f5f8b4ec620>
  pre_request: <function PreRequest.pre_request at 0x7f5f8b4ec730>
  post_request: <function PostRequest.post_request at 0x7f5f8b4ec7b8>
  child_exit: <function ChildExit.child_exit at 0x7f5f8b4ec8c8>
  worker_exit: <function WorkerExit.worker_exit at 0x7f5f8b4ec9d8>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f5f8b4ecae8>
  on_exit: <function OnExit.on_exit at 0x7f5f8b4ecbf8>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: TLSv1
  raw_paste_global_conf: []
[2018-08-10 09:48:40 +0200] [23114] [INFO] Starting gunicorn 19.9.0
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] Arbiter booted
[2018-08-10 09:48:40 +0200] [23114] [INFO] Listening at: http://0.0.0.0:5000 (23114)
[2018-08-10 09:48:40 +0200] [23114] [INFO] Using worker: sync
[2018-08-10 09:48:40 +0200] [23117] [INFO] Booting worker with pid: 23117
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] 1 workers
[2018-08-10 09:48:45 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:48:54 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:00 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:18 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:49:18 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:23 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:37 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:49:37 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:50 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:51:11 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:51:13 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:51:43 +0200] [23114] [CRITICAL] WORKER TIMEOUT (pid:23117)
[2018-08-10 09:51:43 +0200] [23117] [INFO] Worker exiting (pid: 23117)
[2018-08-10 09:51:44 +0200] [23229] [INFO] Booting worker with pid: 23229

पहले की तरह इसका परीक्षण करने के लिए मैं क्रोमियम में http://0.0.0.0:5000/ मार रहा था।
आपके लिए सटीक वातावरण देखने के लिए पिपफाइल और पिपफाइल.लॉक की सामग्री नीचे दी गई है।

पिपफाइल

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
flask = "*"
gunicorn = "*"

[dev-packages]

[requires]
python_version = "3.6"

पिपफाइल.लॉक

{
    "_meta": {
        "hash": {
            "sha256": "81cb5d5f0b11719d8d9c5ec9cc683fdcf959c652fda256d5552a82d0f459a99c"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "click": {
            "hashes": [
                "sha256:29f99fc6125fbc931b758dc053b3114e55c77a6e4c6c3a2674a2dc986016381d",
                "sha256:f15516df478d5a56180fbf80e68f206010e6d160fc39fa508b65e035fd75130b"
            ],
            "version": "==6.7"
        },
        "flask": {
            "hashes": [
                "sha256:2271c0070dbcb5275fad4a82e29f23ab92682dc45f9dfbc22c02ba9b9322ce48",
                "sha256:a080b744b7e345ccfcbc77954861cb05b3c63786e93f2b3875e0913d44b43f05"
            ],
            "index": "pypi",
            "version": "==1.0.2"
        },
        "gunicorn": {
            "hashes": [
                "sha256:aa8e0b40b4157b36a5df5e599f45c9c76d6af43845ba3b3b0efe2c70473c2471",
                "sha256:fa2662097c66f920f53f70621c6c58ca4a3c4d3434205e608e121b5b3b71f4f3"
            ],
            "index": "pypi",
            "version": "==19.9.0"
        },
        "itsdangerous": {
            "hashes": [
                "sha256:cbb3fcf8d3e33df861709ecaf89d9e6629cff0a217bc2848f1b41cd30d360519"
            ],
            "version": "==0.24"
        },
        "jinja2": {
            "hashes": [
                "sha256:74c935a1b8bb9a3947c50a54766a969d4846290e1e788ea44c1392163723c3bd",
                "sha256:f84be1bb0040caca4cea721fcbbbbd61f9be9464ca236387158b0feea01914a4"
            ],
            "version": "==2.10"
        },
        "markupsafe": {
            "hashes": [
                "sha256:a6be69091dac236ea9c6bc7d012beab42010fa914c459791d627dad4910eb665"
            ],
            "version": "==1.0"
        },
        "werkzeug": {
            "hashes": [
                "sha256:c3fd7a7d41976d9f44db327260e263132466836cef6f91512889ed60ad26557c",
                "sha256:d5da73735293558eb1651ee2fddc4d0dedcfa06538b8813a2e20011583c9e49b"
            ],
            "version": "==0.14.1"
        }
    },
    "develop": {}
}

bigunyak 10 अग॰ 2018

बस FYI करें, मैं भी इस विफलता को बहुत नियमित रूप से देख रहा हूँ:

नोहप गनिकोर्न -w 8 --access-logfile=- --bind 127.0.0.1:5000 wsgi &

मेरे पास बस एक wsgi.py है जिसमें है

from chart_api import application
if __name__ == "__main__":
    application.run()

मुझे बताएं कि क्या कुछ है जो आप चाहते हैं कि मैं कोशिश/प्रयोग करूं या यदि लॉग में विशिष्टताएं हैं तो आप मुझे जांचना चाहते हैं। मैं एक GCP VM पर कुप्पी चला रहा हूँ।

jdeltoft 15 अग॰ 2018

देर से उत्तर के लिए क्षमा करें। मैं इसे के रूप में चला रहा हूँ

gunicorn --log-file=/home/ubuntu/log/gunicorn.log भविष्यवक्ता_ एपीआई: ऐप- बी लोकलहोस्ट: 5000 और

मैंने गीवेंट सेटिंग आदि का उपयोग किया था, लेकिन मैंने इस मुद्दे के आसपास काम करने के लिए मुझे इसकी आवश्यकता के बारे में अपना डिज़ाइन बदल दिया है, इसलिए उपरोक्त मूल सेटिंग (जो भी विफल रही लेकिन यह उम्मीद की जा रही है कि कोई गीवेंट नहीं दिया गया है)

पायथन संस्करण 3.6
env: aws tensorflow_p36 ऑप्टिमाइज्ड (उबंटू)
nginx गनिकोर्न के सामने बैठा है, जो एक फ्लास्क ऐप को क्रियान्वित कर रहा है।

फ्लास्क संस्करण 1.0.2
nginx संस्करण 1.10.3
गनिकोर्न संस्करण 19.9.0

मैंने nginx टाइमआउट को भी बदल दिया है और साथ ही इसका कारण हो सकता है।

timoj58 16 अग॰ 2018

गनिकोर्न सर्वर के साथ एक ही समस्या का सामना करना पड़ रहा है

# गनिकोर्न एप्लिकेट आयनसर्वर: ऐप -बी 0.0.0.0:6001 -डब्ल्यू 8 --थ्रेड्स 4 --बैकलॉग 2048 \
# --टाइमआउट 120 --ग्रेसफुल-टाइमआउट 60 --एक्सेस-लॉगफाइल लॉग्स/एक्सेस.लॉग \

--error-logfile logs/error.log --log-level=info

कुप्पी ==0.12.1
गनिकोर्न==19.7.1

जब मैं उपरोक्त कमांड के साथ सर्वर शुरू करता हूं, तो मेरा सिस्टम कुछ समय के लिए फ्रीज हो जाता है और वर्कर पिड्स बूटिंग पर रहते हैं, हालांकि मैंने टाइमआउट 120 सेकंड रखा है, और सर्वर सिंगल रिक्वेस्ट को स्वीकार नहीं कर रहा है।

tiru1930 23 अक्तू॰ 2018

इस मुद्दे पर कोई अपडेट? मेरे पास एक ही मुद्दा है

[महत्वपूर्ण] कार्यकर्ता समय समाप्त

anilpai 5 नव॰ 2018

आश्चर्य है कि क्या किसी ने इसे डॉकर छवि में सफलतापूर्वक पुन: पेश किया है?

javabrett 5 नव॰ 2018

यह भी देखते हुए जब एक मौजूदा एप्लिकेशन पर डेटाडॉग के डीडीट्रेस-रन वर्कर को लागू करने की कोशिश कर रहा है, जो कि गनिकोर्न -के गीवेंट --थ्रेड्स 4 से शुरू हो रहा है।

SystemExit का मज़ेदार निशान मैंने पहले कभी नहीं देखा ...
[2018-11-07 11:11:50 +0000] [15987] [INFO] Booting worker with pid: 15987 [2018-11-07 11:11:50 +0000] [15977] [DEBUG] 1 workers [2018-11-07 11:12:20 +0000] [15977] [CRITICAL] WORKER TIMEOUT (pid:15987) Exception SystemExit: 1 in <bound method LibevLoop._loop_will_run of <cassandra.io.libevreactor.LibevLoop object at 0x7f3cb66d4a50>> ignored

SuicidalTissue 7 नव॰ 2018

मैं श्रमिकों की संख्या और धागे की संख्या का मिलान करके इस मुद्दे को हल करने में सक्षम हूं।

मैंने workers = (2 * cpu_count) + 1 सेट किया था और थ्रेड सेट नहीं किया था।

एक बार जब मैंने threads = workers बदल दिया, तो सब कुछ ठीक काम करने लगा। बस मामले में, अगर यह किसी की मदद करता है।

यह अब कैसा दिखता है

def run(host='0.0.0.0', port=8080, workers=1 + (multiprocessing.cpu_count() * 2)):
    """Run the app with Gunicorn."""

    if app.debug:
        app.run(host, int(port), use_reloader=False)
    else:
        gunicorn = WSGIApplication()
        gunicorn.load_wsgiapp = lambda: app
        gunicorn.cfg.set('bind', '%s:%s' % (host, port))
        gunicorn.cfg.set('workers', workers)
        gunicorn.cfg.set('threads', workers)
        gunicorn.cfg.set('pidfile', None)
        gunicorn.cfg.set('worker_class', 'sync')
        gunicorn.cfg.set('keepalive', 10)
        gunicorn.cfg.set('accesslog', '-')
        gunicorn.cfg.set('errorlog', '-')
        gunicorn.cfg.set('reload', True)
        gunicorn.chdir()
        gunicorn.run()

anilpai 9 नव॰ 2018

👍17

मुझे एडब्ल्यूएस लोचदार बीनस्टॉक पर एक एकल डॉकर कंटेनर के साथ Django चलाने में इस समस्या का सामना करना पड़ा। मैंने यह सुनिश्चित करने के लिए अपने सुरक्षा समूहों को ठीक करके समस्या का समाधान किया कि मेरा EC2 उदाहरण मेरे RDS उदाहरण से बात कर सके। मैं मानता हूं कि यह इस मुद्दे पर 99% लोगों के लिए समाधान नहीं हो सकता है, लेकिन मैं इस नोट को दूसरों की मदद करने के लिए छोड़ रहा हूं ताकि इस खरगोश के छेद में गिरने से घंटों बर्बाद न हो।

clintonb 26 नव॰ 2018

👍14

मेरे मामले में systemctl daemon-reload प्रदर्शन करके समस्या का समाधान किया गया था।
लंबी कहानी छोटी मैं 30sec पर डिफ़ॉल्ट टाइमआउट के बारे में जानता था, लेकिन इसे तब तक बदलने में असमर्थ था जब तक मुझे लगा कि मुझे सेवा में परिवर्तनों को लागू करने के लिए सिस्टमड डेमॉन को फिर से लोड करना होगा।

fred-revel 3 दिस॰ 2018

👍1

@bigunyak @benoitc @tilgovi
एक लंबे Google हंस पीछा और कुछ प्रयोग के बाद मेरा मानना है कि इस मुद्दे का मूल कारण क्रोम "प्रीकनेक्ट/भविष्यवाणी सेवा" है (जो क्रोम और क्रोमियम दोनों में डिफ़ॉल्ट रूप से सक्षम है)।

@जीतिंग ने इस मुद्दे पर अच्छा लिखा
https://hackernoon.com/chrome-preconnect-breaks-singly-threaded-servers-95944be16400
कुछ अतिरिक्त पढ़ना:
https://github.com/corydorf/flask-cors/issues/147
https://github.com/pallets/flask/issues/2169

टीएलडीआर
कुछ मामलों में क्रोम/क्रोमियम एक "खाली" टीसीपी कनेक्शन खोलता है और रखता है (यानी यह भविष्यवाणी करता है कि यह जल्द ही एक और संसाधन लाएगा)। यदि "खाली" टीसीपी कनेक्शन पहले आपके गनिकोर्न सर्वर को हिट करता है तो क्रोम से कोई भी बाद में "वास्तविक" अनुरोध "खाली" अनुरोध के पीछे फंस सकता है जब तक कि कार्यकर्ता "खाली" अनुरोध समय समाप्त नहीं कर लेता। ऐसा होने की अधिक संभावना है यदि आप गनिकोर्न में केवल एक सिंक वर्कर चला रहे हैं। लेकिन जैसा कि मेरे प्रयोगों में पाया गया कि यह तब भी हो सकता है जब आप कई सिंक वर्कर चला रहे हों।

मेरा पर्यावरण

मेरा मूल ओएस उबंटू 17 है
मेरे पास एक स्थानीय डॉकटर कंटेनर में एक बाकी एपीआई चल रहा है। डॉकफाइल से प्रासंगिक पंक्तियाँ

FROM ubuntu:18.04
...
RUN pip3 install Flask==1.0.2
RUN pip3 install gunicorn==19.9.0
RUN pip3 install flask-cors==3.0.6
......

मेरे पास 3 ब्राउज़र स्थापित हैं: फ़ायरफ़ॉक्स 61.0.1, क्रोमियम 67.0.0.3396.99, क्रोम 70.0.0.3538.102
मेरे पास एक प्रतिक्रिया ऐप है जो एक अलग पोर्ट पर एक अलग डॉकटर कंटेनर से परोसा जाता है
प्रतिक्रिया ऐप मेरे एपीआई के लिए सीओआरएस AJAX अनुरोध करता है (वे सीओआरएस अनुरोध हैं क्योंकि जावास्क्रिप्ट एक स्थानीयहोस्ट पोर्ट पर परोसा जाता है जबकि इसकी एपीआई कॉल दूसरे स्थानीयहोस्ट पोर्ट पर भेजती है)
अनुरोध जो मेरे प्रयोगों में हमेशा "अवरुद्ध" हो जाता है वह एक CORS विकल्प अनुरोध है (ब्राउज़र द्वारा POST अनुरोध करने के लिए अनुमति मांगने के लिए ट्रिगर किया जाता है)। तार्किक लगता है कि एक ब्राउज़र विकल्प कॉल के साथ भविष्य कहनेवाला कनेक्शन बनाने की कोशिश करेगा क्योंकि यह एक POST कॉल के साथ अनुवर्ती होने की संभावना है।

प्रयोग 1
Gunicorn कॉन्फिगरेशन: 1 सिंक वर्कर (डिफ़ॉल्ट 30s टाइमआउट)

फ़ायरफ़ॉक्स: लगभग हर प्रतिक्रिया पृष्ठ लोड पर, CORS विकल्प अनुरोध 5s के लिए अवरुद्ध हो जाता है, और फिर सफल होता है।
क्रोमियम: प्रत्येक प्रतिक्रिया पृष्ठ लोड होने पर, CORS विकल्प अनुरोध 1.5 मिनट के लिए अवरुद्ध हो जाता है !!!! और फिर सफल होता है।
क्रोमियम (पूर्वानुमान सेवा अक्षम): सब कुछ ठीक लोड होता है
क्रोम: सब कुछ ठीक लोड होता है

प्रयोग 2
Gunicorn कॉन्फिगरेशन: 4 सिंक वर्कर (डिफ़ॉल्ट 30s टाइमआउट)

फ़ायरफ़ॉक्स: सब कुछ ठीक लोड होता है
क्रोमियम: प्रत्येक तीसरे प्रतिक्रिया पृष्ठ लोड पर, CORS विकल्प अनुरोध 30 सेकंड के लिए अवरुद्ध हो जाता है और फिर सफल होता है।
क्रोमियम (पूर्वानुमान सेवा अक्षम): सब कुछ ठीक लोड होता है
क्रोम: सब कुछ ठीक लोड होता है

प्रयोग 3
Gunicorn कॉन्फिगरेशन: 8 सिंक वर्कर (डिफ़ॉल्ट 30s टाइमआउट)

फ़ायरफ़ॉक्स: सब कुछ ठीक लोड होता है
क्रोमियम: सब कुछ ठीक लोड होता है
क्रोम: सब कुछ ठीक लोड होता है

प्रयोग 4
threaded=True साथ फ्लास्क देव सर्वर चलाएँ

फ़ायरफ़ॉक्स: सब कुछ ठीक लोड होता है
क्रोमियम: सब कुछ ठीक लोड होता है
क्रोम: सब कुछ ठीक लोड होता है

प्रयोग सारांश

ऐसा लगता है कि फ़ायरफ़ॉक्स में भी भविष्यवाणी सेवा है, लेकिन यह अधिक सुंदर लगता है। (प्रयोग 1)
"पूर्वानुमान" कनेक्शन बनाने में क्रोमियम सबसे अधिक आक्रामक लगता है। ऐसा लगता है कि एक विकल्प अनुरोध (प्रयोग 1 और 2) के दौरान 3-4 "पूर्वानुमान" कनेक्शन लॉन्च हो सकते हैं।
आश्चर्यजनक रूप से भले ही क्रोम में भविष्यवाणी सेवा सक्षम हो, लेकिन इसने किसी भी प्रयोग में कोई समस्या नहीं पैदा की (हो सकता है कि क्रम या "पूर्वानुमान" कनेक्शन की संख्या क्रोमियम से अलग हो)

समाधान
उत्पादन में: सबसे आसान फिक्स नगनेक्स को गनिकोर्न के सामने रखना है। यदि आप यह समझना चाहते हैं कि nginx इस मुद्दे को क्यों हल करता है, तो यहां एक अच्छा लेख है जो इसे समझाता है: https://www.brianstorti.com/the-role-of-a-reverse-proxy-to-protect-your-application-against -धीमी गति से ग्राहक/

देव में: सबसे आसान फिक्स threaded=True साथ फ्लास्क देव सर्वर चलाना है। या आप क्रोम/क्रोमियम में पूर्वानुमान सेवा को अक्षम कर सकते हैं।

गनिकोर्न डिबग सुधार
भविष्य में इस तरह की समस्या को डीबग करने में मदद करने के लिए, मुझे लगता है कि सिंक वर्कर में select() और accept() कॉल के आगे डीबग लॉग स्टेटमेंट जोड़ना एक अच्छा विचार है।
https://github.com/benoitc/gunicorn/blob/e974f30517261b2bc95cfb2017a8688f367c8bf3/gunicorn/workers/sync.py#L26
https://github.com/benoitc/gunicorn/blob/e974f30517261b2bc95cfb2017a8688f367c8bf3/gunicorn/workers/sync.py#L34
यह दिखाएगा कि एक कार्यकर्ता ने एक नया टीसीपी कनेक्शन स्वीकार कर लिया है, लेकिन कोई डेटा प्राप्त नहीं कर रहा है।

asnisarenko 11 दिस॰ 2018

👍23 🎉7

@asnisarenko सुपर राइट-अप, धन्यवाद। #1929 स्लो-क्लाइंट का एक और असामान्य मामला है जो सिंगल-थ्रेडेड सर्वर में समान लक्षण देता है - उस स्थिति में, गैर-टीएलएस पोर्ट पर टीएलएस हैंडशेक धीमे-धीमे क्लाइंट की तरह दिखता है, क्योंकि यह समझदार हेडर को जल्दी भेजने में विफल रहता है। .

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

javabrett 11 दिस॰ 2018

👍2

यदि आपके ऐप में ऐसा होता है, तो आप कुछ अस्थायी निदान कोड जोड़ सकते हैं:

def trace_on_abort():
    import signal
    import traceback

    def print_trace(sig, frame):
        print(''.join(traceback.format_stack(frame)))

    signal.signal(signal.SIGABRT, print_trace)

उम्मीद है कि इससे पता चलेगा कि आपका ऐप कहां हैंग होता है।

उदाहरण के लिए, मैं किसी तरह import flask से पहले gevent.monkey.patch_all() कामयाब रहा और इसलिए मेरे फ्लास्क का app._before_request_lock एक गैर-जेवेंट लॉक बन गया (यानी सादा अप्रकाशित threading.Lock )। ऐसे मामले में, ऐप स्टार्ट-अप पर लगातार दो अनुरोधों के कारण यह हैंग हो जाएगा (दूसरा अनुरोध पूरे थ्रेड को लॉक कर देगा)। लेकिन यह मेरी बग थी, और आपकी बग भिन्न हो सकती है।

@asnisarenko मुझे यकीन नहीं है कि आप हैंग का अनुभव क्यों कर रहे हैं। आप बिल्कुल _not_ प्रति कनेक्शन एक कार्यकर्ता की जरूरत है, क्योंकि प्रत्येक कार्यकर्ता हजारों कनेक्शनों को सहकारी रूप से संभाल सकता है (जब तक कि हैंडलिंग कोड सीपीयू पर एकाधिकार नहीं करता है/पूरे धागे को लॉक नहीं करता है)। विशेष रूप से, यदि ब्राउज़र अनुरोध को रोक देता है, तो इसका सीधा सा मतलब है कि जब गनीकॉर्न read() सॉकेट से आता है, तो यह एक ग्रीनलेट को ब्लॉक कर देगा, लेकिन चूंकि read बंदर-पैच होना चाहिए, यह प्राप्त होगा अन्य ग्रीनलेट्स।

ikonst 4 मार्च 2019

👍2 ❤1 🎉1

@ikonst
यह समस्या डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ गनिकोर्न चलाने की बात कर रही है। डिफ़ॉल्ट कार्यकर्ता वर्ग sync http://docs.gunicorn.org/en/stable/settings.html#worker -class है

sync कार्यकर्ता प्री-फोर्क मॉडल का उपयोग करते हैं और प्रत्येक कार्यकर्ता एक समय में एक टीसीपी कनेक्शन/अनुरोध को संसाधित करता है।

asnisarenko 6 मार्च 2019

👍4

मुझे नहीं पता कि यह मेरे लिए क्या कारण है, लेकिन डिफ़ॉल्ट sync कार्यकर्ता प्रकार से eventlet पर स्विच करने से समस्या हल हो गई:

CMD pipenv run gunicorn webapp -b 0.0.0.0:8080 -k eventlet

आपको कामयाबी मिले।

bobf 6 मई 2019

👎4 🎉2 👍2

हो सकता है कि यह केवल मेरी मदद करने वाला हो, लेकिन चूंकि इस मुद्दे को मेरी तरफ से डीबग करने में मुझे 7 घंटे लगे (ईसी 2 पर डॉकर में एक फ्लास्क/गनिकोर्न ऐप चल रहा है), अगर मैं इस सिरदर्द को कुछ लोगों को छोड़ सकता हूं, तो यह एक छोटी सी जीत है।

कंटेनर स्मृति सीमा जो बहुत कम थी।

अगर भविष्य में मेरे पास मेमोरी लीक है, तो मैं एक उच्च मेमोरी लिमिट लगाने की कोशिश करूंगा, लेकिन अभी के लिए, कोई लिमिट नहीं चलेगी।

धन्यवाद

edthrn 7 मई 2019

👍4 ❤1

def trace_on_abort():
    import signal
    import traceback

    def print_trace(sig, frame):
        print(''.join(traceback.format_stack(frame)))

    signal.signal(signal.SIGABRT, print_trace)

आप मेरी बहुत मदद करते हैं। ईएचयू)))

malinich 9 मई 2019

यह trace_on_abort() विधि कहाँ जाती है? ऐप कोड फ़ाइल में? क्या इसे एक एनोटेशन की आवश्यकता है?

mattg-vbt 11 जून 2019

@ mattg-vbt इसे अपने ऐप की शुरुआत में जोड़ें जब आपको डिबग करने की आवश्यकता हो, और डिबगिंग करने के बाद इसे हटा दें

ikonst 11 जून 2019

@ikonst मैंने इसे अपने ऐप में जोड़ा है, लेकिन मुझे यह हिट नहीं दिख रहा है। मुझे कार्यकर्ता टाइमआउट मिलता है, लेकिन यह विधि हिट नहीं होती है।

mattg-vbt 14 जून 2019

👍1

@ mattg-vbt क्या आप kill -ABRT $pid करने का प्रयास कर सकते हैं ताकि print_trace फ़ंक्शन को कॉल किया जा सके? (विचार यह है कि जब आपके कार्यकर्ता का समय समाप्त हो जाता है, तो आपको Werkzeug से SIGABRT मिल जाएगा, लेकिन आइए पहले जांच लें कि इसे बिल्कुल भी कहा जाता है)

ikonst 14 जून 2019

हमारे बीच कम जानकारों के लिए

web gunicorn app:app -k gevent --worker-connections 1000 ?

SumNeuron 19 जुल॰ 2019

@SumNeuron
यदि आप gevent वर्कर्स का उपयोग कर रहे हैं (सिंक वर्कर्स के बजाय) तो आपको इस मुद्दे पर ध्यान नहीं देना चाहिए। तो आपके द्वारा पोस्ट किया गया आदेश ठीक लगता है।

asnisarenko 20 जुल॰ 2019

मुझे यह समस्या केवल इनिशियलाइज़ेशन पर gevent वर्कर्स के साथ मिल रही है, जो थोड़ा कष्टप्रद है क्योंकि मैं अपना ऐप लॉन्च करने से पहले कुछ कार्यों को संसाधित कर रहा हूं। लेकिन मैं अभी के लिए एक हाई टाइमआउट सेट कर रहा हूं।
मैंने यहां एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण रेपो पोस्ट किया है: https://github.com/zamponotiropita/test-gunicorn-worker-timeout -> test_0 विफल रहता है, test_1 और test_2 पास

orestis-z 15 सित॰ 2019

@zamponotiropita क्या आप

ikonst 15 सित॰ 2019

@ikonst कृपया रन फ़ाइल की जाँच करें run.sh , यह प्रति कार्यकर्ता है। समस्या प्रीलोडिंग के साथ नहीं आई थी, लेकिन प्रीलोडिंग करते समय मुझे डेटाबेस से कनेक्ट करने में समस्याएं थीं, क्योंकि ऐप ऑब्जेक्ट (और इसके साथ डेटाबेस कनेक्शन के साथ) कॉपी हो जाता है और फोर्किंग करते समय प्रक्रियाओं को पारित कर देता है -> मेरा डेटाबेस संभाल नहीं सका मास्टर और श्रमिकों के समान कनेक्शन, और मुझे कोई समाधान नहीं मिला

orestis-z 16 सित॰ 2019

मेरी भी इसी प्रकार की समस्या है। मैं फ्लास्क का उपयोग करके बहुत सारे डेटा ऑन-द-फ्लाई उत्पन्न करने की कोशिश कर रहा हूं
यह विधि, और यह विफल हो जाती है क्योंकि --timeout में जो कुछ भी सेट किया गया था उसके बाद कार्यकर्ता का समय समाप्त हो जाता है। पुन: पेश करने के लिए एक न्यूनतम उदाहरण:

test_gunicorn_timeout.py

import flask
from time import sleep


app = flask.Flask(__name__)


@app.route('/')
def gunicorn_timeout():
    def generator():
        for _ in range(10):
            yield b'Yet another line...'
            sleep(2)
    return flask.Response(generator(), mimetype='text/plain')

फिर gunicorn --timeout 10 test_gunicorn_timeout:app चलाएं और 10 सेकंड के बाद localhost:8000 अनुरोध करने पर आपको a
[CRITICAL] WORKER TIMEOUT ।

मैंने -k gevent और -k eventlet साथ चलने की भी कोशिश की और कुछ भी नहीं बदला।

ltskv 17 अक्तू॰ 2019

मैं विंडोज 10 प्रो पर हूं। डॉकर कंपोज़ के साथ
gunicorn app -b 0.0.0.0:8000 -k gevent
मेरे अजगर कंटेनर में gevent स्थापित करके मेरे लिए काम किया
गीवेंट कैसे स्थापित करें

ShubhamKhandare 17 अक्तू॰ 2019

फिर gunicorn --timeout 10 test_gunicorn_timeout:app चलाएं और 10 सेकंड के बाद localhost:8000 अनुरोध करने पर आपको a
[CRITICAL] WORKER TIMEOUT ।
मैंने -k gevent और -k eventlet साथ चलने का भी प्रयास किया और कुछ भी नहीं बदला।

@ltskv

क्या आपको [क्रिटिकल] वर्कर टाइमआउट समस्या का समाधान मिल गया है?

मुझे फ्लास्क स्ट्रीमिंग एंडपॉइंट के साथ एक ही समस्या है, मैं उसकेोकू (जो गनिकोर्न का उपयोग करता है) पर तैनात करने की कोशिश कर रहा हूं। वहां, प्रॉक्सी फ्रंटएंड को कनेक्शन को तब तक जीवित रखना चाहिए जब तक कि कुछ डेटा 30 सेकंड के भीतर भेजा जाता है, लेकिन ऐसा लगता है कि गनिकोर्न केवल प्रक्रिया को मारता है अगर यह 30 सेकंड के भीतर समाप्त नहीं हुआ है, भले ही यह अभी भी चल रहा है और डेटा का उत्पादन कर रहा है।

इस बिंदु पर मेरे लिए गनिकोर्न प्रलेखन पूरी तरह से स्पष्ट नहीं है। --timeout के लिए यह कहता है कि Workers silent for more than this many seconds are killed and restarted. लेकिन ऐसा लगता है कि श्रमिकों को 30sec के बाद मार दिया जाता है, भले ही वे अभी भी डेटा का उत्पादन करते हैं?

kurt-hectic 31 अक्तू॰ 2019

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

@ कर्ट-हेक्टिक कि दस्तावेज़ीकरण में सुधार किया जाना चाहिए। मौन से हमारा तात्पर्य मध्यस्थ प्रक्रिया के दृष्टिकोण से मौन से है, जो एक अस्थायी फ़ाइल के माध्यम से श्रमिकों के साथ संचार करता है। यदि कार्यकर्ता डेटा भेजने में व्यस्त है, तो वह उस फ़ाइल को अपडेट नहीं करता है। मध्यस्थ के नजरिए से, कार्यकर्ता दिल की धड़कन याद कर रहा है।

#1974 भी देखें।

tilgovi 31 अक्तू॰ 2019

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

tilgovi 31 अक्तू॰ 2019

@ कर्ट-हेक्टिक मैंने एक बार फिर से -k gevent विकल्प की दोबारा जांच की और जेनरेटर पुनरावृत्तियों के बीच sleep(0) डाला और यह वास्तव में मेरे लिए काम करता था (मुझे यकीन नहीं है कि यह उस समय क्यों काम नहीं करता था मैंने हालांकि सवाल पोस्ट किया)।

ltskv 1 नव॰ 2019

--टाइमआउट=5

यह इस समस्या का सबसे आम कारण है।

sandeepsign 5 नव॰ 2019

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

यहाँ मेरी समझ और समाधान हैं:

गनिकोर्न में प्रीलोड करने का प्रयास करें

यह श्रमिकों को बूट करने में विफल रहता है क्योंकि पैकेज को लोड करने के लिए अधिक समय की आवश्यकता होती है, जैसे कि टेंसरफ़्लो बैकएंड, सेवा शुरू करने के लिए। इसलिए जब आप धीमे ऐप बूट समय का अनुभव कर रहे हों, तो गनिकोर्न में प्रीलोड विकल्प को सक्षम करने का प्रयास करें (देखें https://devcenter.heroku.com/articles/python-gunicorn#advanced-configuration)।

गनिकोर्न हैलो: ऐप --preload

गनिकोर्न के लिए समयबाह्य बढ़ाने का प्रयास करें

डिफ़ॉल्ट टाइमआउट 30s है। यदि आपके एप्लिकेशन को वास्तव में एक एपीआई समाप्त करने के लिए अधिक समय चाहिए, तो टाइमआउट बढ़ाएं।

गनिकोर्न हैलो: ऐप --टाइमआउट 10

हालाँकि, मेरे दृष्टिकोण से, इसका कोई मतलब नहीं है अगर किसी एपीआई को समाप्त होने में 1 मिनट से अधिक की आवश्यकता हो। यदि हां, तो अपने कोड में कुछ प्रगति करने का प्रयास करें।

यदि आप k8s का उपयोग कर रहे हैं, तो आप yaml में कंटेनर/छवि के लिए टाइमआउटसेकंड भी सेट कर सकते हैं।

lc-lingliang 17 नव॰ 2019

👍12 ❤8

मुझे आज उसी मुद्दे का सामना करना पड़ा। मेरे मामले में एपीआई को डेटा की गणना करने और क्लाइंट के पास लौटने में लगभग एक मिनट का समय लग रहा था, जिसके परिणामस्वरूप क्रिटिकल वर्कर टाइमआउट त्रुटियाँ हुईं। मैंने इसे एक मिनट से अधिक समय तक गनिकोर्न के लिए टाइमआउट ध्वज बढ़ाकर हल किया - यह काम किया, इस मुद्दे को वापस नहीं देखा। उम्मीद है की यह मदद करेगा। मैं uvicorn.workers.UvicornWorker का उपयोग कर रहा हूं।

rubyfin 30 दिस॰ 2019

मैंने gnuicorn में अतिरिक्त कर्मचारियों को जोड़कर इसे ठीक किया:

web: gunicorn --workers=3 BlocAPI:app --log-file -

पता नहीं क्यों।

alpinechicken 5 जन॰ 2020

शायद आपके पास गतिरोध था? क्या आपका ऐप खुद से अनुरोध करता है?

सूर्य पर, 5 जनवरी 2020, 10:52 अल्पाइनचिकन, नोटिफिकेशन @github.com ने लिखा:

मैंने gnuicorn में अतिरिक्त कर्मचारियों को जोड़कर इसे ठीक किया:
वेब: गनिकोर्न --वर्कर्स = 3 ब्लॉकएपीआई: ऐप --लॉग -फाइल -
पता नहीं क्यों।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJVQRCW3C63EZJWIN5DQ4G3WTA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVREXG43DVTVH
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAAEQJXZM4NLK56DZMFSZALQ4G3WTANCNFSM4FDLD5PA
.

bobf 5 जन॰ 2020

हाँ एक मार्ग दूसरे को बुलाता है - क्या वह बुरा है?

alpinechicken 6 जन॰ 2020

इसका मतलब है कि आपको कम से कम दो श्रमिकों की आवश्यकता है अन्यथा आपका सर्वर होगा
गतिरोध अनुरोध तब तक प्रतीक्षा करेगा जब तक सर्वर दूसरे का जवाब नहीं देता
अनुरोध (जो कतारबद्ध होगा)।

आपको प्रति कार्यकर्ता एक समवर्ती अनुरोध मिलता है।

सोम, 6 जनवरी 2020, 2:45 alpinechicken पर, [email protected] लिखा है:

हाँ एक मार्ग दूसरे को बुलाता है - क्या वह बुरा है?
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJSFEFBBI6AMZJCM4C3Q4KLOJA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW#PI
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAAEQJXTCPOFIZJU5PUPOODQ4KLOJANCNFSM4FDLD5PA
.

bobf 6 जन॰ 2020

👍1

आह यह समझ में आता है। धन्यवाद!

मंगल, 7 जनवरी, 2020 6:23 पूर्वाह्न bobf पर पर [email protected] लिखा है:

इसका मतलब है कि आपको कम से कम दो श्रमिकों की आवश्यकता है अन्यथा आपका सर्वर होगा
गतिरोध अनुरोध तब तक प्रतीक्षा करेगा जब तक सर्वर दूसरे का जवाब नहीं देता
अनुरोध (जो कतारबद्ध होगा)।
आपको प्रति कार्यकर्ता एक समवर्ती अनुरोध मिलता है।
सोम, 6 जनवरी 2020, 2:45 alpinechicken पर, [email protected] लिखा है:
हाँ एक मार्ग दूसरे को बुलाता है - क्या वह बुरा है?
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
<
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJSFEFBBI6AMZJCM4C3Q4KLOJA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63PI
,
या सदस्यता समाप्त करें
<
https://github.com/notifications/unsubscribe-auth/AAAEQJXTCPOFIZJU5PUPOODQ4KLOJANCNFSM4FDLD5PA
.
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAH2WRPVPVO2EJ53BKQW5B3Q4OHLRA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVREXG43VMVB7JQTGODNMVX
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAH2WRM2LLIB4O6OHCU5UG3Q4OHLRANCNFSM4FDLD5PA
.

alpinechicken 6 जन॰ 2020

वर्कर_क्लास', 'सिंक')

मैं श्रमिकों की संख्या और धागे की संख्या का मिलान करके इस मुद्दे को हल करने में सक्षम हूं।
मैंने workers = (2 * cpu_count) + 1 सेट किया था और थ्रेड सेट नहीं किया था।
एक बार जब मैंने threads = workers बदल दिया, तो सब कुछ ठीक काम करने लगा। बस मामले में, अगर यह किसी की मदद करता है।
यह अब कैसा दिखता है
def run(host='0.0.0.0', port=8080, workers=1 + (multiprocessing.cpu_count() * 2)):
    """Run the app with Gunicorn."""

    if app.debug:
        app.run(host, int(port), use_reloader=False)
    else:
        gunicorn = WSGIApplication()
        gunicorn.load_wsgiapp = lambda: app
        gunicorn.cfg.set('bind', '%s:%s' % (host, port))
        gunicorn.cfg.set('workers', workers)
        gunicorn.cfg.set('threads', workers)
        gunicorn.cfg.set('pidfile', None)
        gunicorn.cfg.set('worker_class', 'sync')
        gunicorn.cfg.set('keepalive', 10)
        gunicorn.cfg.set('accesslog', '-')
        gunicorn.cfg.set('errorlog', '-')
        gunicorn.cfg.set('reload', True)
        gunicorn.chdir()
        gunicorn.run()

Gunicorn doc के अनुसार, यदि एक से अधिक थ्रेड्स का उल्लेख किया गया है, तो यह वर्कर क्लास को सिंक से gthread में बदल देता है।
पुनश्च:-
यदि आप सिंक वर्कर प्रकार का उपयोग करने का प्रयास करते हैं और थ्रेड्स सेटिंग को 1 से अधिक पर सेट करते हैं, तो इसके बजाय gthread वर्कर प्रकार का उपयोग किया जाएगा।

sambit9238 9 जन॰ 2020

मेरा मामला:

पर्यावरण: Ubuntu18.04+ gunicorn+ nginx +flask

मेरे आभासी वातावरण में pip install gunicorn[gevent]

gunicorn -b localhost:8000 -w 4 web:app को gunicorn -b localhost:8000 -k gevent web:app बदलें

यह काम करता हैं।

CharlesHehe 13 जन॰ 2020

यहां उन सभी लोगों को धन्यवाद जिन्होंने अपने मुद्दों को सुलझाने में एक-दूसरे की मदद करने के लिए बहुत कुछ किया है। यदि उचित लगे तो कृपया इस मुद्दे पर पोस्ट करना जारी रखें।

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

कृपया मेरे इरादे को गलत न समझें। यदि आपको Gunicorn में किसी बग का संदेह है और आप चर्चा जारी रखना चाहते हैं, तो कृपया ऐसा करें। अधिमानतः, एक उदाहरण एप्लिकेशन के साथ एक नया टिकट खोलें जो आपकी समस्या को पुन: उत्पन्न करता है। हालाँकि, इस बिंदु पर, इस मुद्दे में बहुत अधिक भिन्न समस्याएँ, समाधान और वार्तालाप हैं, ताकि यह बहुत सुपाठ्य हो।

यदि आप इसके सामने बिना बफरिंग रिवर्स प्रॉक्सी के Gunicorn चलाते हैं, तो आप कई कारणों से डिफ़ॉल्ट, सिंक वर्कर के साथ टाइमआउट प्राप्त कर सकते हैं। आम हैं:

धीमे ग्राहक
ब्राउज़र और प्रॉक्सी द्वारा खुले छोड़े गए कनेक्शन को प्री-कनेक्ट / प्रीफ़ेच करें
बाहरी एपीआई को कॉल करने या बहुत सारे सीपीयू-बाध्य कार्य करने के कारण लंबी प्रतिक्रियाएं

आप एसिंक्रोनस या थ्रेडेड वर्कर प्रकारों पर स्विच कर सकते हैं, या आप गनिकोर्न को बफरिंग रिवर्स प्रॉक्सी के पीछे रख सकते हैं। यदि आप जानते हैं कि आपके समयबाह्य आपके अपने कोड के कारण बाहरी एपीआई को धीमी कॉल करने या महत्वपूर्ण कार्य करने की वजह से हैं, तो आप --timeout विकल्प बढ़ा सकते हैं।

tilgovi 13 फ़र॰ 2020

👍11

इसका मतलब है कि आपको कम से कम दो कर्मचारियों की आवश्यकता है अन्यथा आपका सर्वर गतिरोध करेगा। अनुरोध तब तक प्रतीक्षा करेगा जब तक सर्वर दूसरे अनुरोध का जवाब नहीं देता (जो कतारबद्ध होगा)। आपको प्रति कार्यकर्ता एक समवर्ती अनुरोध मिलता है।
…
सोम, 6 जनवरी 2020, 02:45 अल्पाइनचिकन, @ पर । * > लिखा: हाँ एक रास्ता दूसरे को बुलाता है - क्या वह बुरा है?

क्या यह मामला है जब 'रीडायरेक्ट' फ़ंक्शन को रूट के रिटर्न वैल्यू के रूप में कॉल किया जाता है?

abkeble 3 मार्च 2020

क्या यह मामला है जब 'रीडायरेक्ट' फ़ंक्शन को रूट के रिटर्न वैल्यू के रूप में कॉल किया जाता है?

नहीं। एक फ्लास्क रीडायरेक्ट एक HTTP रीडायरेक्ट के साथ प्रतिक्रिया करता है और कार्यकर्ता तब एक नया अनुरोध स्वीकार करने के लिए स्वतंत्र होता है। जब ग्राहक इस प्रतिक्रिया को देखता है तो एक और अनुरोध करता है और जब भी कोई कार्यकर्ता तैयार होता है तो उसे यह अनुरोध प्राप्त होगा।

tilgovi 3 मार्च 2020

मैंने gnuicorn में अतिरिक्त कर्मचारियों को जोड़कर इसे ठीक किया:
web: gunicorn --workers=3 BlocAPI:app --log-file -
पता नहीं क्यों।

क्या यह पहले @anilpai की टिप्पणी से संबंधित है जहां उन्होंने workers=1 + (multiprocessing.cpu_count() * 2) .. सेट किया था?

Shane-Neeley 11 मार्च 2020

मेरे पास इसी तरह का मुद्दा था। पता चला कि आवेदन के लिए मेरे प्रवेश बिंदु में मुझे एक त्रुटि हुई थी। डिबगिंग से ऐसा लग रहा था कि मैं अनिवार्य रूप से गनिकोर्न से एक फ्लास्क ऐप लॉन्च कर रहा था, जिसके कार्यकर्ता बाद में एक अनंत कनेक्शन लूप में प्रवेश करते हैं जो हर 30 के दशक में होता है।

मुझे यकीन है कि यह उपरोक्त सभी उपयोगकर्ताओं को प्रभावित नहीं करता है, लेकिन कुछ को प्रभावित कर सकता है।

मेरी module/wsgi.py फ़ाइल में जो मैं gunicorn module.wsgi साथ चला रहा हूं, मेरे पास थी -

application = my_create_app_function()
application.run(host="0.0.0.0")

जबकि मुझे होना चाहिए था -

application = my_create_app_function()
if __name__ == "__main__":
     application.run(host="0.0.0.0")

अनिवार्य रूप से, आप गनिकोर्न का उपयोग करते समय application.run() पर कॉल नहीं करना चाहते हैं। __name__ गनिकोर्न के तहत "__main__" नहीं होगा, लेकिन यह फ्लास्क में होगा, इसलिए आप अभी भी स्थानीय रूप से डीबग कर सकते हैं।

मुझे इसका संदर्भ गनिकोर्न डॉक्स में नहीं मिला, लेकिन यह एक सामान्य त्रुटि मामला होने की कल्पना कर सकता है, इसलिए शायद कुछ चेतावनी आवश्यक है।

Justice4Joffrey 1 मई 2020

👍2

यह अभी भी हो रहा है। Gunicorn कॉल में --preload जोड़ने से मेरे लिए समस्या ठीक हो गई।

JurajMa 15 जून 2020

क्या यह बग अभी भी ठीक नहीं हुआ है? मैं इस सटीक व्यवहार को देख रहा हूं।

सिस्टमड में Gunicorn इस तरह शुरू होता है:

[Service]
PIDFile = /run/gunicorn.pid
WorkingDirectory = /home/pi/pyTest
ExecStart=/usr/local/bin/gunicorn  app:app  -b 0.0.0.0:80 --pid /run/gunicorn.pid
RuntimeDirectory=/home/pi/pyTest
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
User=root
Group=root
ExecReload = /bin/kill -s HUP $MAINPID
ExecStop = /bin/kill -s TERM $MAINPID
ExecStopPost = /bin/rm -rf /run/gunicorn
PrivateTmp = true

कार्यकर्ता प्रक्रिया लगातार समय समाप्त होती है और पुनरारंभ होती है:

Jul 10 15:19:20 raspberryVM gunicorn[10941]: [2020-07-10 15:19:20 -0700] [10941] [CRITICAL] WORKER TIMEOUT (pid:10944)
Jul 10 15:19:20 raspberryVM gunicorn[10941]: [2020-07-10 15:19:20 -0700] [10944] [INFO] Worker exiting (pid: 10944)
Jul 10 15:20:15 raspberryVM gunicorn[10941]: [2020-07-10 15:20:15 -0700] [10985] [INFO] Booting worker with pid: 10985

app.py एक ट्रिवल फ्लास्क ऐप है।

क्या यह समस्या ठीक न करें के रूप में बंद है?

leonbrag 11 जुल॰ 2020

मुझे भी यही समस्या हो रही थी

लेकिन डिबगिंग के बाद मैं यह पता लगाने में सक्षम हूं कि जब गनिकॉर्न Django ऐप शुरू करता है तो निर्भरता में से एक अपेक्षित समय से अधिक समय ले रहा था, (मेरे मामले में बाहरी डीबी कनेक्शन) जो gunicron कार्यकर्ता को टाइमआउट करने के लिए बनाता है

जब मैंने कनेक्शन समस्या का समाधान किया, तो टाइमआउट समस्या भी हल हो गई ...

midhuntp 6 अग॰ 2020

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

leonbrag 6 अग॰ 2020

@leonbrag
यह संभवतः एक गनिकोर्न बग नहीं है। धागे में ऊपर मेरी प्रशंसा देखें। यह खाली "अनुमानित" टीसीपी कनेक्शन भेजने वाले ब्राउज़रों का साइड-इफेक्ट है, और खाली टीसीपी कनेक्शन से सुरक्षा के बिना केवल कुछ सिंक श्रमिकों के साथ गनिकोर्न चला रहा है।

asnisarenko 8 अग॰ 2020

क्या कोई संदर्भ वास्तुकला/डिज़ाइन है जो लंबे (स्थायी) कार्यकर्ता धागे के साथ गनिकोर्न फ्लास्क ऐप को स्थापित करने का एक उचित तरीका दिखाता है?

यदि यह एक बग नहीं है, तो यह एक आर्टिफैक्ट या गनिकोर्न आर्किटेक्चर/डिज़ाइन की सीमा प्रतीत होता है।

सिंक कार्यकर्ता हमेशा के लिए क्यों नहीं चलेगा और क्लाइंट कनेक्शन स्वीकार करेगा। ऐसा कार्यकर्ता आवश्यकतानुसार सॉकेट बंद कर देगा, फिर भी बिना बाहर निकले चलना जारी रखेगा (और इसके लिए कार्यकर्ता धागा चलना जारी रहेगा)।

leonbrag 8 अग॰ 2020

@leonbrag
आप जिस समस्या को हल करने का प्रयास कर रहे हैं उसके बारे में आपको अधिक विशिष्ट होना चाहिए।

इस धागे में चर्चा की गई समस्या देव वातावरण में होती है और सबसे आसान समाधान या तो अधिक सिंक श्रमिकों को जोड़ना है या थ्रेडेड श्रमिकों का उपयोग करना है।

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

यह एक अच्छा पठन है।
https://www.brianstorti.com/the-role-of-a-reverse-proxy-to-protect-your-application-against-slow-clients/

asnisarenko 8 अग॰ 2020

आप दस्तावेज़ीकरण से डिज़ाइन पृष्ठ की जांच कर सकते हैं। Async कार्यकर्ता एक है
लंबे कार्यों को चलाने का तरीका।

शनि 8 अगस्त 2020 18:00 leonbrag पर पर [email protected] लिखा है:

क्या कोई संदर्भ आर्किटेक्चर/डिज़ाइन है जो सेट अप करने का उचित तरीका दिखाता है
लंबे (स्थायी) कार्यकर्ता धागे के साथ गनिकोर्न फ्लास्क ऐप?
अगर यह बग नहीं है, तो यह एक आर्टिफैक्ट या इसकी सीमा लगती है
Gunicorn वास्तुकला / डिजाइन।
सिंक कार्यकर्ता हमेशा के लिए क्यों नहीं चलेगा और क्लाइंट कनेक्शन स्वीकार करेगा। ऐसा
कार्यकर्ता आवश्यकतानुसार सॉकेट बंद कर देगा, फिर भी बाहर निकलने के बिना चलना जारी रखेगा
(और इसलिए कार्यकर्ता धागा चलना जारी रखता है)।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/1801#issuecomment-670944797 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAADRIWRQGIP3R5PMVJ5ENTR7VZA3ANCNFSM4FDLD5PA
.
>

मेरे मोबाइल से भेजा गया

benoitc 9 अग॰ 2020

वेब: गनिकोर्न - वर्कर्स = 3 ऐप: ऐप - टाइमआउट 200 - लॉग-फाइल -

मैंने --timeout . को बढ़ाकर अपनी समस्या का समाधान किया

AlejandroRodriguezP 4 सित॰ 2020

👍6 🚀2 ❤2

डॉकर से संबंधित tmpfs मुद्दों के लिए #1388 भी देखें।

ओह, बहुत बहुत धन्यवाद रान्डेल, जब मैं डॉकर में गनिकोर्न चला रहा था, तो मैं गनिकोर्न तर्कों में --worker-tmp-dir /dev/shm जोड़ना भूल गया था।

बीटीडब्ल्यू 64 एमबी गनिकोर्न कैश के लिए पर्याप्त होगा?

ivictbor 22 नव॰ 2020

गनिकोर्न ऐप: ऐप --टाइमआउट 1000
या
गनिकोर्न ऐप: ऐप --preload

मेरे लिए काम किया ... मैं टाइमआउट एक पसंद करता हूं।

attajutt 27 नव॰ 2020

अजीब, मैंने --worker-tmp-dir /dev/shm जोड़ा लेकिन फिर भी प्राप्त कर रहा हूं:

[2020-11-27 21:01:42 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)

यह सुनिश्चित करने के लिए कि /dev/shm ramfs है मैंने इसे बेंचमार्क किया है:

पैरा अगले हैं:

    command: /bin/bash -c "cd /code/ && pipenv run gunicorn --worker-tmp-dir /dev/shm conf.wsgi:application --bind 0.0.0.0:8022 --workers 5 --worker-connections=1000"

पुनश्च: मैं PyPy का उपयोग कर रहा हूँ

@attajutt टाइमआउट अच्छा है लेकिन आप जोखिम उठा रहे हैं कि गनिकोर्न मास्टर प्रक्रिया केवल 1000 सेकंड के बाद आपकी कार्यकर्ता प्रक्रिया में हैंगअप का पता लगाएगी, और आप बहुत सारे अनुरोधों को याद करेंगे। साथ ही यह पता लगाना मुश्किल होगा कि क्या कई श्रमिकों में से केवल एक ही हैंगअप करेगा। मैं कम से कम 1000 तो नहीं करूंगा।

ivictbor 27 नव॰ 2020

@ivictbor एलएमके के लिए धन्यवाद। 1000 संदर्भ के लिए है। फिर भी, एक बार लोड होने के बाद मुझे ऐप रोलिंग मिल गया यह पूरी तरह से ठीक चल रहा है।

attajutt 28 नव॰ 2020

मुझे यह त्रुटि समस्या भी मिली और कई बार के बाद, मैंने पाया कि समस्या शायद कारण है:

नग्नेक्स विन्यास
Gunicorn / Uwsgi

यदि आप अपने ऐप को जीएई जैसे क्लाउड में तैनात करते हैं, तो इससे कुछ भी संकेत त्रुटि नहीं दिखाई देगी।
आप इस मामले के समाधान का उपयोग करके त्रुटि को सामने लाने का प्रयास कर सकते हैं: https://stackoverflow.com/questions/38012797/google-app-engine-502-bad-gateway-with-nodejs

अगर उठाया 502 खराब गेटवे;
शायद 2 संभावनाएं होंगी:

गनिकोर्न नहीं चल रहा है
गनिकोर्न का समय समाप्त हो गया

पूरा समाधान यहाँ समझाया गया है: https://www.datadoghq.com/blog/nginx-502-bad-gateway-errors-gunicorn/

उम्मीद है कि किसी को भी [क्रिटिकल] वर्कर टाइमआउट में त्रुटि मिली है, इसे ठीक कर सकते हैं

Subrata15 14 मार्च 2021

इस सूत्र को खोजने वालों के लिए एक और संभावना जोड़ना...

यह डॉकर लगाए गए संसाधन बाधाओं के कारण भी हो सकता है जो आपके वेब एप्लिकेशन के लिए बहुत कम हैं। उदाहरण के लिए मेरे पास निम्नलिखित बाधाएं थीं:

services:
  web_app:
    image: blah-blah
    deploy:
      resources:
        limits:
          cpus: "0.25"
          memory: 128M

और ये स्पष्ट रूप से gunicorn लिए बहुत कम थे इसलिए मुझे लगातार [CRITICAL] WORKER TIMEOUT त्रुटि मिली जब तक कि मैंने बाधाओं को हटा नहीं दिया।

coltonbh 26 मार्च 2021

👍1

गनिकोर्न के लिए यह संसाधन पूरी तरह से ठीक हैं। लेकिन आपको वास्तव में चाहिए
श्रमिकों की संख्या और आपके लिए आवश्यक संसाधनों के लिए विमान
आवेदन। वेब एप्लिकेशन के लिए 128M और 0.25cpu वास्तव में कम लगता है
पायथन में लिखा है .... आम तौर पर बोलते हुए आपको कम से कम 1 कोर/वीसीपीयू की आवश्यकता होती है और
512MB RAM न्यूनतम के रूप में।

शुक्रवार 26 मार्च 2021 को 02:14 बजे, कोल्टन हिक्स @ . * > लिखा है:

इस सूत्र को खोजने वालों के लिए एक और संभावना जोड़ना...
यह डॉकटर द्वारा लगाए गए संसाधन अवरोधों के कारण भी हो सकता है कि
आपके वेब एप्लिकेशन के लिए बहुत कम हैं। उदाहरण के लिए मेरे पास निम्नलिखित था
प्रतिबंध:
सेवाएं:
वेब अप्प:
छवि: ब्ला ब्लाह
तैनाती:
साधन:
सीमाएं:
सीपीयू: "0.25"
मेमोरी: 128M
और ये स्पष्ट रूप से गनिकोर्न के लिए बहुत कम थे इसलिए मुझे लगातार [क्रिटिकल] मिला
कार्यकर्ता टाइमआउट त्रुटि जब तक मैं बाधाओं को हटा नहीं देता।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/1801#issuecomment-807855647 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAADRITPZB7BMA6QW7LFNVLTFPNV3ANCNFSM4FDLD5PA
.
>

मेरे मोबाइल से भेजा गया

benoitc 26 मार्च 2021

👍4

--टाइमआउट = 1000 ने मेरे रूप में काम किया। समस्या एक कम-सीपीयू संसाधन वाली जीसीपी मशीन थी। यह मेरी स्थानीय मशीन पर डिफ़ॉल्ट टाइमआउट के साथ ठीक काम करता है।

dplutcho 31 मार्च 2021

👍5

Gunicorn: फ्लास्क ऐप चलाते समय क्रिटिकल वर्कर टाइमआउट

सबसे उपयोगी टिप्पणी

सभी 82 टिप्पणियाँ

--error-logfile logs/error.log --log-level=info

>

>

संबंधित मुद्दों