<p>गनिकोर्न क्रिटिकल वर्कर टाइमआउट</p>

जब एक कार्यकर्ता टाइमआउट करता है तो इसका मतलब है कि उसने मध्यस्थ को समय पर सूचित नहीं किया कि वह जीवित था। क्या आपके पास अनुरोध के दौरान कोई कार्य निष्पादित किया गया है जिसमें टाइमआउट से अधिक समय लग सकता है?

@jseaidou टक्कर।

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

मैं बिल्कुल उसी मुद्दे का सामना कर रहा हूं।
गनिकोर्न 19.7.1
गीवेंट 1.2.1
पायथन 3.5.3
डॉकर में चल रहा है, आधिकारिक " पायथन: 3.5 " पर आधारित छवि

@jseaidou यह इस अर्थ में असामान्य टाइमआउट है कि मध्यस्थ इस पर प्रतिक्रिया करता है। यह महत्वपूर्ण है क्योंकि यह सामान्य रूप से नहीं होना चाहिए।

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

मैं इस मुद्दे को कैसे पुन: पेश कर सकता हूं?

@saabeilin वही ^^

मैं वही देख रहा हूं: कोई अनुरोध नहीं करने पर भी कार्यकर्ता समय निकाल रहे हैं। मैंने जो कुछ किया है वह मेरा कंटेनर एडब्ल्यूएस ईसीएस पर लॉन्च किया गया है।

[2017-06-27 20:41:56 +0000] [1] [DEBUG] Current configuration:
proxy_protocol: False
worker_connections: 1000
statsd_host: None
max_requests_jitter: 0
post_fork: <function post_fork at 0x7f6bbc3f1938>
errorlog: -
enable_stdio_inheritance: False
worker_class: sync
ssl_version: 2
suppress_ragged_eofs: True
syslog: False
syslog_facility: user
when_ready: <function when_ready at 0x7f6bbc3f1668>
pre_fork: <function pre_fork at 0x7f6bbc3f17d0>
cert_reqs: 0
preload_app: False
keepalive: 2
accesslog: -
group: 0
graceful_timeout: 30
do_handshake_on_connect: False
spew: False
workers: 4
proc_name: None
sendfile: None
pidfile: None
umask: 0
on_reload: <function on_reload at 0x7f6bbc3f1500>
pre_exec: <function pre_exec at 0x7f6bbc3f1ed8>
worker_tmp_dir: None
limit_request_fields: 100
pythonpath: None
on_exit: <function on_exit at 0x7f6bbc3f7758>
config: None
logconfig: None
check_config: False
statsd_prefix:
secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
reload_engine: auto
proxy_allow_ips: ['127.0.0.1']
pre_request: <function pre_request at 0x7f6bbc3f70c8>
post_request: <function post_request at 0x7f6bbc3f71b8>
forwarded_allow_ips: ['127.0.0.1']
worker_int: <function worker_int at 0x7f6bbc3f1c08>
raw_paste_global_conf: []
threads: 1
max_requests: 0
chdir: /opt/app
daemon: False
user: 0
limit_request_line: 4094
access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
certfile: None
on_starting: <function on_starting at 0x7f6bbc3f1398>
post_worker_init: <function post_worker_init at 0x7f6bbc3f1aa0>
child_exit: <function child_exit at 0x7f6bbc3f7320>
worker_exit: <function worker_exit at 0x7f6bbc3f7488>
paste: None
default_proc_name: app:app
syslog_addr: udp://localhost:514
syslog_prefix: None
ciphers: TLSv1
worker_abort: <function worker_abort at 0x7f6bbc3f1d70>
loglevel: DEBUG
bind: ['0.0.0.0:5005']
raw_env: []
initgroups: False
capture_output: False
reload: False
limit_request_field_size: 8190
nworkers_changed: <function nworkers_changed at 0x7f6bbc3f75f0>
timeout: 30
keyfile: None
ca_certs: None
tmp_upload_dir: None
backlog: 2048
logger_class: gunicorn.glogging.Logger
[2017-06-27 20:41:56 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-06-27 20:41:56 +0000] [1] [DEBUG] Arbiter booted
[2017-06-27 20:41:56 +0000] [1] [INFO] Listening at: http://0.0.0.0:5005 (1)
[2017-06-27 20:41:56 +0000] [1] [INFO] Using worker: sync
[2017-06-27 20:41:56 +0000] [8] [INFO] Booting worker with pid: 8
[2017-06-27 20:41:57 +0000] [9] [INFO] Booting worker with pid: 9
[2017-06-27 20:41:57 +0000] [10] [INFO] Booting worker with pid: 10
[2017-06-27 20:41:57 +0000] [12] [INFO] Booting worker with pid: 12
[2017-06-27 20:41:57 +0000] [1] [DEBUG] 4 workers
[2017-06-27 20:42:15 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:15 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-06-27 20:42:46 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-06-27 20:42:46 +0000] [12] [INFO] Worker exiting (pid: 12)
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 3 workers
[2017-06-27 20:42:46 +0000] [24] [INFO] Booting worker with pid: 24
[2017-06-27 20:42:46 +0000] [25] [INFO] Booting worker with pid: 25
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 4 workers

स्थानीय रूप से चलते समय ऐसा नहीं होता है। :-/

ऐसा लगता है कि gevent कर्मचारियों पर स्विच करने से मेरे लिए समस्या का समाधान हो गया है। \_(ツ)_/¯

#1194 का डुप्लिकेट, मुझे लगता है।

मैंने इसे हाल ही में बार-बार होते देखा है, और मेरे लिए यह लैपटॉप को सोने से जुड़ा हुआ लगता है। जब मैं ढक्कन खोलता हूं, तो इन संदेशों का एक गुच्छा दिखाई देता है। यकीन नहीं होता कि यह मदद करता है, लेकिन मैंने सोचा कि मैं इसका उल्लेख करूंगा ...

गनिकोर्न --डेमन --वर्कर्स 2 --टाइमआउट 120 --बाइंड 127.0.0.1:4000 --pid /var/run/mshc_admin.pid --user danilovskoe --group danilovskoe --chdir /home/danilovskoe/mshc2/src /फ्लास्क/ --env MSHC_PRODUCTION=/etc/monit/mshc.config.py admin_ gunicorn:app

समय समाप्त 30 सेकंड
अनुरोध प्राप्त करें

उबंटू 16.04
फ्लास्क 0.12.2
पायथन 3.6.3 (डिफ़ॉल्ट, 4 अक्टूबर 2017, 02:55:45)
[जीसीसी 5.4.0 20160609] लिनक्स पर
गनिकोर्न (संस्करण 19.7.1)

मैं परेशानी से मिला।

ऐप शुरू करने के बाद ही यह काम करता है। लेकिन केवल अगर कोई अनुरोध है, तो [CRITICAL] WORKER TIMEOUT ट्रिगर किया जाएगा। उदाहरण के लिए,

[2018-01-02 16:38:03 +0800] [24355] [INFO] Starting gunicorn 19.7.1
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] Arbiter booted
[2018-01-02 16:38:03 +0800] [24355] [INFO] Listening at: http://0.0.0.0:8080 (24355)
[2018-01-02 16:38:03 +0800] [24355] [INFO] Using worker: gevent
[2018-01-02 16:38:03 +0800] [24358] [INFO] Booting worker with pid: 24358
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] 1 workers

[2018-01-02 16:38:10 +0800] [24358] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] Closing connection. 
[2018-01-02 16:38:41 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24358)
[2018-01-02 16:38:41 +0800] [24358] [INFO] Worker exiting (pid: 24358)
[2018-01-02 16:38:41 +0800] [24381] [INFO] Booting worker with pid: 24381

[2018-01-02 16:48:51 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24381)
[2018-01-02 16:48:51 +0800] [24381] [INFO] Worker exiting (pid: 24381)
[2018-01-02 16:48:51 +0800] [24703] [INFO] Booting worker with pid: 24703
[2018-01-02 16:48:51 +0800] [24703] [INFO] worker pid 24703 notify
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] Closing connection. 

CentOS: 6.7
Python: 3.6.3
Gevent: 1.2.2
Greenlet: 0.4.9
Gunicorn: 19.7.1

RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

जब मैंने कार्यकर्ता वर्ग को eventlet स्विच किया, अर्थात,
gunicorn --worker-class eventlet --log-level debug --bind 0.0.0.0:8080 app ,
ठीक है।

सूचना: मेरा ऐप भौतिक होस्ट पर चलता है, न तो वर्चुअल होस्ट और न ही क्लाउड होस्ट।

अद्यतन:

तो मुझे लगता है कि यह gevent या gevent कार्यकर्ता का सवाल है।

इस मुद्दे पर समस्या को हल करने और समस्या पैदा करने वाले gevent पर रिपोर्टें हैं। मैं यहां मूल कारण की पहचान नहीं कर सकता। कुछ रिपोर्ट #1194 जैसी हो सकती हैं, लेकिन अन्य शायद नहीं।

अगर कोई पुन: पेश करने के लिए न्यूनतम मामला साझा कर सकता है, तो इससे मदद मिलेगी।

मुझे यकीन नहीं है कि यह निश्चित रूप से एक ही मुद्दा है, लेकिन मैं निम्नलिखित सेटअप के साथ वर्चुअलबॉक्स का उपयोग करके इस 100% समय को पुन: पेश कर सकता हूं:

होस्ट: विंडोज 10
अतिथि: उबंटू 16.04
गनिकॉर्न: 19.7.1

मैं डिफ़ॉल्ट NAT कनेक्शन पर होस्ट और अतिथि के बीच TCP: 8000 अग्रेषित करता हूं। sync कार्यकर्ता का उपयोग करके, होस्ट पर localhost:8000 लिए कोई भी अनुरोध लॉग में इन त्रुटियों को प्रकट करने का कारण बनता है, लेकिन यदि मैं अतिथि पर वही अनुरोध करता हूं, तो लॉग स्पष्ट है। --worker-class eventlet स्विच करने से ट्रेस हट जाता है।

मैं सराहना करता हूं कि वर्चुअलबॉक्स एक पूरी तरह से अलग आयाम है, लेकिन यह ऊपर वर्णित के समान ही लगता है, और लगातार प्रतिलिपि प्रस्तुत करने योग्य है (मेरे लिए कम से कम)।

मैं इसे धीमे अपलोड के साथ होते देख रहा हूं। अपलोड के दौरान (एक Django साइट पर) यदि कार्यकर्ता टाइमआउट हिट हो जाता है, तो अपलोड मर जाता है।

@lordmauve यदि आप अपेक्षित सिंक कार्यकर्ता का उपयोग कर रहे हैं। लंबे अनुरोध कार्यकर्ता को रोक देंगे और अंत में मध्यस्थ उसे मार डालेगा। यदि आप लंबे अनुरोधों के सफल होने की अपेक्षा करते हैं, तो आप एक भिन्न कार्यकर्ता प्रकार का उपयोग कर सकते हैं।

इस धागे को पढ़ने वाले किसी भी व्यक्ति के लिए, कृपया पुन: पेश करने के लिए न्यूनतम मामले के साथ फिर से खोलें। मैं यहां आगे बढ़ने के लिए कोई साफ जांच नहीं देख सकता। एडब्ल्यूएस / ईसीएस के मामले में, मैं अभी भी #1194 खुला छोड़ रहा हूं जब तक कि मैं अपने द्वारा सूचीबद्ध कॉन्फ़िगरेशन का परीक्षण नहीं कर सकता (https://github.com/benoitc/gunicorn/issues/1194#issuecomment-371250650)।

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

मुझे यह समस्या हो रही थी जब मैंने डॉकर झुंड का उपयोग करके अपने आवेदन को तैनात करने का प्रयास किया और महसूस किया कि मैं आवेदन के लिए संसाधन को बहुत कम कर रहा था। संसाधन बढ़ाने से मेरे लिए समस्या का समाधान हो जाता है

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

मुझे लगता है कि यह कोई बग नहीं है, जिस तरह से हम अपने ऐप्स को कॉन्फ़िगर करते हैं

@jseaidou यह इस अर्थ में असामान्य टाइमआउट है कि मध्यस्थ इस पर प्रतिक्रिया करता है। यह महत्वपूर्ण है क्योंकि यह सामान्य रूप से नहीं होना चाहिए।

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

मैं इस मुद्दे को कैसे पुन: पेश कर सकता हूं?

@saabeilin वही ^^

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