Gunicorn: डॉकर + एडब्ल्यूएस . पर गनिकोर्न सिंक वर्कर्स टाइम आउट

ऊपर लॉग से hrmmm मैं देख सकता हूँ कि समय कभी नहीं बदल रहा है। मैं जाँच करूँगा

धन्यवाद मैं इसकी प्रशंसा करता हूँ!

मैं इस बग से प्रभावित हो सकता हूं।

मैं एडब्ल्यूएस (लोचदार बीनस्टॉक + ईसी 2 कंटेनर सेवा) पर एक डोकर छवि के अंदर gunicorn चला रहा हूँ।
निरंतर कार्यकर्ता टाइमआउट होते हैं जो प्रारंभ होने के लगभग तुरंत बाद होने लगते हैं, और केवल एडब्ल्यूएस पर डॉकर छवि चलाते समय।
एक ही HTTP अनुरोध में कभी-कभी कुछ ms, कभी-कभी 20-30 सेकंड लगते हैं। कोई फर्क नहीं पड़ता कि यह एक गैर-मौजूद पृष्ठ के लिए है, एक साधारण गैर-प्रमाणित "हैलो वर्ल्ड" -स्ट्रिंग पृष्ठ या एक पृष्ठ जो डेटाबेस से रिकॉर्ड प्राप्त करता है।

अतिरिक्त विवरण :

• Gunicorn संस्करण : 19.5.0 और 19.6.0।
• बेस डॉकर छवि : पायथन: 3.4 ( ओएस : डेबियन जेसी)
• डॉकर संस्करण : 1.9.1 (अमेज़ॅन ईसीएस द्वारा प्रबंधित), ओएस : अमेज़ॅन लिनक्स एएमआई 2016.03 (अमेज़ॅन ईबी द्वारा प्रबंधित)।
• वेब अनुप्रयोग ढांचा : Django संस्करण 1.9.6 और 1.9.7।

परिवेश _नहीं_प्रभावित :

• स्थानीय मशीन , दोनों _inside_ और _outside_ एक डॉकर कंटेनर। ओएस : उबंटू 16.04 एलटीएस, डॉकर : 1.11.2।
• हेरोकू ( ओएस : उबंटू 14.04 एलटीएस)

अमेज़न कंटेनर लॉग :

[2016-06-15 16:46:15 +0000] [1] [DEBUG] Current configuration:
  cert_reqs: 0
  post_request: <function PostRequest.post_request at 0x7fb13e187c80>
  worker_connections: 1000
  tmp_upload_dir: None
  enable_stdio_inheritance: False
  timeout: 30
  pre_fork: <function Prefork.pre_fork at 0x7fb13e1871e0>
  worker_int: <function WorkerInt.worker_int at 0x7fb13e1876a8>
  backlog: 2048
  max_requests: 0
  max_requests_jitter: 0
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  logconfig: None
  syslog_addr: udp://localhost:514
  preload_app: False
  pidfile: None
  umask: 0
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  paste: None
  proxy_protocol: False
  worker_class: sync
  on_starting: <function OnStarting.on_starting at 0x7fb13e414c80>
  worker_abort: <function WorkerAbort.worker_abort at 0x7fb13e187840>
  worker_exit: <function WorkerExit.worker_exit at 0x7fb13e187e18>
  config: config/gunicorn.py
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7fb13e18a048>
  daemon: False
  accesslog: None
  errorlog: -
  loglevel: debug
  syslog_prefix: None
  ssl_version: 3
  suppress_ragged_eofs: True
  limit_request_field_size: 8190
  reload: False
  logger_class: gunicorn.glogging.Logger
  statsd_host: None
  keyfile: None
  raw_env: []
  threads: 1
  django_settings: None
  proc_name: None
  proxy_allow_ips: ['127.0.0.1']
  limit_request_fields: 100
  ciphers: TLSv1
  check_config: False
  do_handshake_on_connect: False
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7fb13e187510>
  graceful_timeout: 30
  worker_tmp_dir: None
  certfile: None
  sendfile: None
  keepalive: 2
  chdir: /app/testapp
  when_ready: <function WhenReady.when_ready at 0x7fb13e187048>
  ca_certs: None
  on_exit: <function OnExit.on_exit at 0x7fb13e18a1e0>
  spew: False
  bind: [':8000']
  post_fork: <function Postfork.post_fork at 0x7fb13e187378>
  limit_request_line: 4094
  syslog_facility: user
  workers: 3
  syslog: False
  pre_request: <function PreRequest.pre_request at 0x7fb13e187b70>
  user: 0
  group: 0
  forwarded_allow_ips: ['127.0.0.1']
  pythonpath: None
  on_reload: <function OnReload.on_reload at 0x7fb13e414e18>
  pre_exec: <function PreExec.pre_exec at 0x7fb13e1879d8>
  default_proc_name: config.wsgi
  statsd_prefix: 
[2016-06-15 16:46:15 +0000] [1] [INFO] Starting gunicorn 19.5.0
[2016-06-15 16:46:15 +0000] [1] [DEBUG] Arbiter booted
[2016-06-15 16:46:15 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2016-06-15 16:46:15 +0000] [1] [INFO] Using worker: sync
[2016-06-15 16:46:15 +0000] [8] [INFO] Booting worker with pid: 8
[2016-06-15 16:46:15 +0000] [9] [INFO] Booting worker with pid: 9
[2016-06-15 16:46:15 +0000] [10] [INFO] Booting worker with pid: 10
[2016-06-15 16:46:15 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2016-06-15 16:46:52 +0000] [9] [INFO] Worker exiting (pid: 9)
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:10)
[2016-06-15 16:46:52 +0000] [10] [INFO] Worker exiting (pid: 10)
[2016-06-15 16:46:53 +0000] [20] [INFO] Booting worker with pid: 20
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 2 workers
[2016-06-15 16:46:53 +0000] [21] [INFO] Booting worker with pid: 21
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:47:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
(...)

`

धन्यवाद।

मैं यह भी देख रहा हूं। मेरा संदेह इलास्टिक लोड बैलेंसर है। हम पिछली कंपनी में paste का उपयोग करते थे और यह ELB के साथ समस्याएँ पैदा कर रहा था। मेरा मानना ​​​​है कि यह किसी भी तरह कनेक्शन का पुन: उपयोग करता है और यह paste में हिचकी पैदा कर रहा था।

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

इसके बजाय gevent श्रमिकों का उपयोग करने का प्रयास करें, इससे मेरे लिए समस्या हल हो गई है।

तो क्या यह ईएलबी के कनेक्शन को जीवित रखने और सिंक वर्कर को बांधने का मुद्दा है? यह मुझे बहुत अजीब लगेगा क्योंकि हम जानबूझकर संकेत देते हैं कि सिंक कार्यकर्ता के साथ कनेक्शन बंद होना चाहिए: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L168

हालाँकि, हम जान-बूझकर कनेक्शन बंद कर सकते थे। अगर कोई client.close() कॉल को बिना शर्त स्थानांतरित करने का परीक्षण करना चाहता है जो एक दिलचस्प परीक्षा हो सकती है: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L199

आप यह भी सुनिश्चित कर सकते हैं कि ईएलबी पर निष्क्रिय टाइमआउट वर्कर टाइमआउट से कम है, एक त्वरित विवेक के रूप में जांच करें कि यह समस्या का कारण भी है: http://docs.aws.amazon.com/elasticloadbalancing/latest/ Classic/config-idle-timeout.html

@tilgovi एल्ब चीज मेरा वर्तमान सबसे अच्छा अनुमान है, क्योंकि ए) यह केवल तभी होता है जब गनिकोर्न ईएलबी के पीछे होता है और बी) समस्या gevent कार्यकर्ता का उपयोग करके तय की जाती है। लेकिन फिर, कौन जानता है ..

यह केवल ELB के पीछे होता है, और यदि प्रोटोकॉल HTTP या HTTPS ELB पर सेट है।
यदि आप प्रोटोकॉल को टीसीपी या एसएसएल में बदलते हैं तो समस्या गायब हो जाती है।
क्या कोई जानता है कि इसे अभी भी सिंक वर्कर्स का उपयोग करके कैसे ठीक किया जाए? मैंने अब तक वर्णित फिक्स (HTTP के बजाय टीसीपी) का उपयोग किया है, जब मैं एक्सेस लॉग की निगरानी करने जा रहा हूं और एक्स-फॉरवर्डेड-हेडर के लिए देख रहा हूं, जो केवल ईएलबी पर HTTP/HTTPS के लिए सक्षम है :)

अजीब, बस यह सुनिश्चित करने के लिए कि हम एक ही पृष्ठ पर हैं, इसका मतलब है कि ईएलबी में HTTP/HTTPS विकल्प का उपयोग करते समय किसी प्रकार का अनुकूलन होता है? और यह अनुकूलन सिंक कर्मचारियों के साथ समस्याएँ पैदा कर रहा है?

@ecs मुझे लगता है कि HTTP/HTTPS लोड बैलेंसर के मामले में उसी टीसीपी कनेक्शन का पुन: उपयोग किया जाता है, जिसे

बीटीडब्ल्यू, निश्चित रूप से बहुत सारे कारक हैं (गनिकॉर्न संस्करण, कार्यकर्ता वर्ग, डॉकटर के अंदर या नहीं, ईएलबी प्रोटोकॉल) जो प्रभावित कर सकते हैं, इसलिए यह बहुत अच्छा हो सकता है यदि कोई परीक्षण करेगा और पुष्टि करेगा कि ईएलबी पर टीसीपी प्रोटोकॉल HTTP के विपरीत काम करता है। मैं उबंटू 14.04 और गनिकोर्न संस्करण 19.3.0 पर होस्ट किए गए डॉकटर पर परीक्षण कर रहा हूं

मुझे भी यही समस्या है:
[२०१६-१०-०३ १२:१३:१७ +००००] [६] [महत्वपूर्ण] कार्यकर्ता समय समाप्त (पीआईडी:१६)
[२०१६-१०-०३ १२:१३:१७ +००००] [१६] [सूचना] बाहर निकलने वाला कार्यकर्ता (पीआईडी: १६)
[२०१६-१०-०३ १२:१३:१७ +००००] [६] [महत्वपूर्ण] कार्यकर्ता समय समाप्त (पीआईडी:२०)
[२०१६-१०-०३ १२:१३:१७ +००००] [२०] [सूचना] बाहर निकलने वाला कार्यकर्ता (पीआईडी: २०)
[२०१६-१०-०३ १२:१३:१७ +००००] [३३] [जानकारी] पीआईडी ​​के साथ बूटिंग कार्यकर्ता: ३३

मेरा सेटअप।

मैं एडब्ल्यूएस पर कोर-ओएस के साथ कुबेरनेट्स क्लस्टर स्थापित करने के लिए क्यूब-एडब्ल्यूएस का उपयोग कर रहा हूं: https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws

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

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

हमारे एक ऐप के साथ भी यही अजीब समस्या थी। श्रोताओं को HTTP से tcp में बदलने से वास्तव में समस्या हल हो जाती है।

कोई भी मुझे इस मुद्दे को पुन: पेश करने के लिए चरण-दर-चरण तरीका प्रदान कर सकता है? (कॉन्फ़िगरेशन चरण और ऐसे) या कम से कम मुझे उस वातावरण को स्थापित करने के लिए एक आसान तरीके से इंगित करें :) मैं इस सप्ताह इस पर एक नज़र डालेगा।

ऐसे बैलेंसर के लिए HTTP पर भरोसा करने के लिए आम तौर पर कीप-अलाइव को संभालने की आवश्यकता होती है, (टीसीपी को छोड़कर) इसलिए सिंक वर्कर का उपयोग करने वाली कोई भी चीज तब तक एक समस्या हो सकती है जब तक कि सिंक वर्कर को इसके समर्थन के लिए अपडेट नहीं किया जाएगा।

वैसे भी मुझे बताएं।

बस एक बुनियादी फ्लास्क ऐप सेट करें और इसे HTTP लोड-बैलेंसिंग और ऊपर से कॉन्फ़िगरेशन के साथ AWS पर डॉक के अंदर सिंक वर्कर्स के साथ गनिकोर्न के साथ चलाएं:

एक डॉक इमेज के अंदर गनिकोर्न 19.4.5 का उपयोग करना, जो एडब्ल्यूएस पर उबंटू 14.04 एलटीएस पर चल रहा है, मुझे> 1 सिंक वर्कर और डिफ़ॉल्ट 30 के टाइमआउट अवधि के साथ चलते समय निरंतर वर्कर टाइमआउट दिखाई देता है।

आपको आवेदन के लिए कोई अनुरोध करने की आवश्यकता नहीं है, बस लॉग की निगरानी करें और आप श्रमिकों को समय समाप्त होते देखेंगे।

• मैं इस व्यवहार के साथ-साथ इसे पुन: पेश करने के मूल दृष्टिकोण की पुष्टि कर सकता हूं।
  
  
  
  • व्यवहार डॉकर तक ही सीमित नहीं है बल्कि सिंक वर्कर/रखरखाव सेटिंग तक सीमित है, ताकि आप शीर्षक बदलने पर विचार कर सकें ...
  
  
• मैंने पालन करने के लिए रखरखाव सेटिंग को संशोधित किया है जो यहां वर्णित है: https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ (सबसे दिलचस्प हिस्सा उद्धरण है एडब्ल्यूएस ईएलबी दस्तावेज से) और सर्वर को अब इस व्यवहार को प्रदर्शित नहीं करने के लिए मिला।
• इसके अलावा मैं अतिरिक्त रूप से gthread कार्यकर्ता वर्ग में बदल गया हूं और परिणाम को अब तक बहुत स्वीकार्य पाया है।

मैं वर्तमान में 65s टाइमआउट अवधि (AWS ELB टाइमआउट 60s, AFAIK) के साथ gevent वर्कर्स का उपयोग कर रहा हूं। मैं अभी भी कभी-कभी 504 त्रुटियों का अनुभव करता हूं, तब भी जब केवल एक ग्राहक अनुरोध करता है, एक बार में उड़ान में 1 अनुरोध के साथ, लेकिन मैं अभी तक एक कारण बताने में सक्षम नहीं था।

@obi1kenobi क्या आपने रखवाले को बढ़ाने की कोशिश की?

@lenucksi रखरखाव पहले से ही 5s तक

मुझे भी एक ईएलबी के पीछे एक ईसी 2 इंस्टेंस पर डॉकर कंटेनर के अंदर गनिकोर्न 19.6 चलाने में इस समस्या का सामना करना पड़ा (ईसी 2 इंस्टेंस के लिए रिवर्स-प्रॉक्सिंग के लिए डिफ़ॉल्ट HTTP प्रोटोकॉल का उपयोग करना)।

जैसा कि पहले सुझाव दिया गया था, वर्कर क्लास को गीवेंट पर सेट करने से मेरे लिए यह समस्या हल हो गई (जहां पहले मैं डिफ़ॉल्ट sync वर्कर क्लास का उपयोग कर रहा था)।

मैं इस मुद्दे को पुन: उत्पन्न करने के लिए एक न्यूनतम उदाहरण का प्रयास और दस्तावेज करूंगा।

दूसरों ने जो कहा है उसकी पुष्टि करने के लिए, ईएलबी ईसी 2 इंस्टेंस के लिए एक कनेक्शन खोल रहा है और इसे इस तरह से खुला रखता है जो अतिरिक्त अनुरोधों को संभालने से गनिकोर्न को लॉक कर देता है।

जब वह होल्ड-ओपन कनेक्शन ईएलबी से अनुरोध के समय समाप्त होने के कारण समाप्त हो जाता है, तो इसके पीछे कतारबद्ध सभी लंबित अनुरोध भी विफल हो जाते हैं (ईएलबी की स्वास्थ्य जांच सहित, जिसके कारण ईएलबी से इंस्टेंस को हटा दिया जाता है, जिससे इसे डीबग करना कठिन हो जाता है; ) )

यह लक्षण बताता है कि यह पिछले अंक में जो देखा गया है उसका डुप्लिकेट है जो डॉकर से असंबंधित है: https://github.com/benoitc/gunicorn/issues/588

@jelis क्या आप जानते हैं कि यह कुछ कुबेरनेट्स कॉन्फ़िगरेशन से संबंधित है या नहीं? क्या आपकी समस्या का समाधान हुआ?

मैं एसएसएल समाप्ति के साथ ईएलबी पर भी हूं। मैं इसे अपने लॉग में देख रहा हूं:

[017-03-01 07:36:32 +0000] [1249] [DEBUG] GET /healthcheck
[01/Mar/2017:07:36:32 +0000] "GET /healthcheck HTTP/1.1" 200 22 "-" "ELB-HealthChecker/1.0"
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1203)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1225)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1234)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1243)
[017-03-01 07:36:37 +0000] [1203] [INFO] Worker exiting (pid: 1203)
[017-03-01 07:36:37 +0000] [1225] [INFO] Worker exiting (pid: 1225)
[017-03-01 07:36:37 +0000] [1243] [INFO] Worker exiting (pid: 1243)
[017-03-01 07:36:37 +0000] [1234] [INFO] Worker exiting (pid: 1234)
[017-03-01 07:36:37 +0000] [1256] [INFO] Booting worker with pid: 1256
[017-03-01 07:36:37 +0000] [12] [DEBUG] 14 workers
[017-03-01 07:36:37 +0000] [1257] [INFO] Booting worker with pid: 1257
[017-03-01 07:36:37 +0000] [1262] [INFO] Booting worker with pid: 1262
[017-03-01 07:36:37 +0000] [1265] [INFO] Booting worker with pid: 1265
[017-03-01 07:36:37 +0000] [12] [DEBUG] 16 workers
[017-03-01 07:36:40 +0000] [1262] [DEBUG] GET /healthcheck

अपडेट - मैंने अभी-अभी गनिकोर्न से गीवेंट (http://flask.pocoo.org/docs/0.12/deploying/wsgi-standalone/#gevent) पर स्विच किया है और समस्या हल हो गई है। यह मेरी उपरोक्त टिप्पणी के संदर्भ में है https://github.com/benoitc/gunicorn/issues/1194#issuecomment -283269046

मैं इस मुद्दे पर दो दिनों से विचार कर रहा हूं। यहां सभी के नोट्स शानदार हैं, और हमें सुधार/समाधान/शमन करने के लिए कई रास्ते दे रहे हैं। (मेरे काम का लॉग उस बग में है जिसे हम यहां ट्रैक कर रहे

मैंने केवल कार्यकर्ता संख्या में वृद्धि के साथ गीवेंट के उपयोग का प्रयास किया और इससे हमें बिल्कुल भी मदद नहीं मिली - वास्तव में इसने आश्चर्यजनक रूप से इसे बदतर बना दिया - सभी पांच गीवेंट श्रमिकों की एक ही समय में मृत्यु हो गई, जो कि एक नया व्यवहार है मैंने ऊपर क्या पढ़ा है:

[2017-03-30 23:38:37 +0000] [5] [INFO] Starting gunicorn 19.7.1
[2017-03-30 23:38:37 +0000] [5] [INFO] Listening at: http://0.0.0.0:8000 (5)
[2017-03-30 23:38:37 +0000] [5] [INFO] Using worker: eventlet
[2017-03-30 23:38:38 +0000] [8] [INFO] Booting worker with pid: 8
[2017-03-30 23:38:40 +0000] [9] [INFO] Booting worker with pid: 9
[2017-03-30 23:38:41 +0000] [11] [INFO] Booting worker with pid: 11
[2017-03-30 23:38:42 +0000] [12] [INFO] Booting worker with pid: 12
[2017-03-30 23:38:42 +0000] [10] [INFO] Booting worker with pid: 10
[2017-03-30 23:40:08 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:8)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:10)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-03-30 23:40:13 +0000] [8] [INFO] Worker exiting (pid: 8)
[2017-03-30 23:40:13 +0000] [10] [INFO] Worker exiting (pid: 10)
[2017-03-30 23:40:16 +0000] [16] [INFO] Booting worker with pid: 16
[2017-03-30 23:40:16 +0000] [17] [INFO] Booting worker with pid: 17
[2017-03-30 23:40:18 +0000] [18] [INFO] Booting worker with pid: 18
[2017-03-30 23:40:20 +0000] [19] [INFO] Booting worker with pid: 19
[2017-03-30 23:40:23 +0000] [20] [INFO] Booting worker with pid: 20

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

मेरे पास एक समान सेटअप है (ईएलबी-> ईसीएस डॉकर कंटेनर-> गनिकोर्न-> डीजेंगो चल रहा है) और मैं पुष्टि कर सकता हूं कि निम्नलिखित कॉन्फ़िगरेशन परिवर्तनों ने मदद की है:

keepalive = 75 # needs to be longer than the ELB idle timeout
timeout = 90
worker_class = 'gevent'

मैंने अपना ईएलबी निष्क्रिय टाइमआउट 60 सेकंड पर सेट किया है।

इन सेटिंग्स को बदलने से पहले मैं कीपलाइव, टाइमआउट और सिंक वर्कर के लिए डिफॉल्ट का उपयोग कर रहा था।

दिलचस्प बात यह है कि यह मुद्दा 10 अप्रैल को सुबह 4 बजे यूटीसी प्रदर्शित होना शुरू हुआ। ऐप पिछले गुरुवार से बिना किसी बदलाव के ठीक चल रहा था।

बस ढेर, कोई डॉकटर नहीं, लेकिन नंगे एडब्ल्यूएस उदाहरण एक ईएलबी के पीछे एक ही मुद्दा था। ओएसएक्स पर एनपी काम करता है, लेकिन एक ईएलबी के साथ ubuntu16 एक ही मुद्दा सामने आया। gevent कार्यकर्ता वर्ग इसे [मेरे लिए] ठीक करता प्रतीत होता है।

क्या इस धागे में कोई इसकी जांच कर सकता है?
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

ऐसा लगता है कि

वैकल्पिक रूप से, ईएलबी के लिए निष्क्रिय समयबाह्य कम करें।

जंगली (या एक नापाक ग्राहक) में कोई ग्राहक ईएलबी की तरह काम नहीं कर सकता और उसी मुद्दे का कारण बन सकता है?

@ छह8 हाँ। ईएलबी आपको इससे भी नहीं बचाता है। दस्तावेज़ीकरण इस पर चर्चा करता है: http://docs.gunicorn.org/en/latest/design.html#choosing -a-worker-type

कुछ लोग इस खतरे की परवाह नहीं करते हैं और केवल ELB के किनारे या पीछे Gunicorn को तैनात करना चाहते हैं। यहां जिस मुद्दे पर चर्चा की गई है, वह ईएलबी की वजह से वर्कर टाइमआउट है। मैं अनुशंसित कॉन्फ़िगरेशन प्रदान करना चाहता हूं जो सिंक श्रमिकों के साथ और अतिरिक्त रिवर्स प्रॉक्सी के बिना ईएलबी के पीछे गनिकोर्न काम करता है।

मैं करने के लिए gunicorn मंगलाचरण बदलकर रूप में अच्छी तरह के समाधान की कोशिश की @erikcw:

CMD [ "gunicorn", "-k", "gevent", "--timeout", "10", "--keep-alive", "75", "--paste", "/etc/jzoo/app.ini" ]

दुर्भाग्य से यह मदद नहीं करता है:

[2017-07-04 08:36:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:24)
[2017-07-04 08:38:11 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:28)
[2017-07-04 08:39:39 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:29)
[2017-07-04 08:44:14 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-07-04 08:44:55 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:31)

मेरे पास Gunicorn सिंक वर्कर्स के साथ ALB के पीछे ECS पर चलने वाला एप्लिकेशन है। मैंने अभी तक कोई मुद्दा नहीं देखा है।

क्या कोई प्रतिलिपि प्रस्तुत करने योग्य तैनाती प्रदान कर सकता है?

ढेर, साथ ही। ईएलबी के साथ एडब्ल्यूएस पर कुबेरनेट्स का उपयोग करके इस मुद्दे को देखकर। वर्तमान में 8 कर्मचारी चल रहे हैं। प्रति https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ , हम keepalive ऊपर जा रहे हैं, और इस थ्रेड के अनुसार कोशिश करने जा रहे हैं इसके बजाय gevent श्रमिकों का उपयोग करने के लिए। लेकिन अभी, जो विफल हो रहा है वह एपीआई कॉल के लिए कुछ प्रदर्शन परीक्षण हैं जो अपने आप को अवरुद्ध/समयबाह्य नहीं करना चाहिए। जानना चाहते हैं कि यहां sync श्रमिकों के साथ क्या हो रहा है। भले ही हम इस धागे में कुछ अच्छे दिशानिर्देशों के अनुसार काम कर रहे हों, हम उत्पादन में तैनात करने से पहले क्या हो रहा है इसके बारे में थोड़ा और विश्वास चाहते हैं।

--worker-class को --worker-class gevent सेट करना मेरे लिए काम कर गया। टिप्पणियों और मदद के लिए धन्यवाद!

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

कृपया, इस थ्रेड पर हर कोई, एक ऐसा एप्लिकेशन प्रदान करें जो इस समस्या को पुन: उत्पन्न करता है। मैं इसे पुन: पेश करने में सक्षम नहीं हूं। पुनरुत्पादन के चरणों के बिना, मैं बंद करने का लुत्फ उठा रहा हूं। इन टिप्पणियों में कई तरह की सिफारिशें और शायद बहुत अलग मुद्दे दबे हुए हैं। यह जानना मुश्किल है कि इस मुद्दे का क्या करना है।

@tilgovi मैंने इस समस्या का अनुभव तब किया जब कार्यकर्ता वर्ग को https://github.com/7ideas/cookiecutter-falcon से कुकी कटर का उपयोग किया और सभी नवीनतम पैकेजों में अपग्रेड किया और ब्राउज़र में sample_resource लोड करने की कोशिश में और httpie के साथ इसे कई बार हिट करने से अंतःक्रियात्मक रूप से कार्यकर्ता क्रैश त्रुटि दिखाई देगी ( उदाहरण के लिए अनुरोध में देरी होगी और फिर मुझे त्रुटि दिखाई देगी; अगर मैंने अनुरोध रद्द नहीं किया तो यह अंततः जवाब देगा)। यह केवल सिंक के डिफ़ॉल्ट कार्यकर्ता वर्ग के साथ हुआ। जब मैंने इसे गीवेंट का उपयोग करने के लिए निर्दिष्ट किया, तो सब कुछ काम कर गया।

धन्यवाद, @ jhillhouse92 , मैं इसे

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

ध्यान देने योग्य बात यह है कि मैंने उपरोक्त स्टैक के साथ स्थानीय रूप से डॉकर/एडब्ल्यूएस/ईएलबी के भीतर इस मुद्दे का अनुभव नहीं किया।

इसलिए मैं गीवेंट का उपयोग कर रहा हूं, अपने एक्सेस लॉग को कैप्चर करने की कोशिश कर रहा हूं, और एडब्ल्यूएस/ईएलबी का उपयोग करके अपने ऐप को तैनात करने की कोशिश कर रहा हूं।

डॉकरफाइल कमांड:

FROM cortex/base

CMD ["gunicorn", "-w", "8", "-b", "0.0.0.0:5000", "--capture-output", "--enable-stdio-inheritance", "--access-logfile", "-", "--worker-class", "gevent", "-t", "60", "--log-level", "debug", "app:app"]

मुझे त्रुटि कोड 14 के संबंध में पागल ओओएम त्रुटियां मिल रही हैं, भले ही मैंने सीमाएं निर्धारित की हों। क्या किसी और ने इसे इस मुद्दे के संदर्भ में देखा है? पहले, मैं वर्कर टाइमआउट देख पा रहा था। मेरी वर्तमान कॉन्फ़िगरेशन के साथ, मैं टाइमआउट को पुन: उत्पन्न नहीं कर सकता/अब तक प्राप्त नहीं कर सकता।

[2017-07-19 18:27:39 +0000] [34] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/ggevent.py", line 190, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.load_wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/usr/local/lib/python3.5/site-packages/gunicorn/util.py", line 376, in import_app
    __import__(module)
  File "/code/app/__init__.py", line 2, in <module>
    from flask_alchy import Alchy
  File "/usr/local/lib/python3.5/site-packages/flask_alchy.py", line 8, in <module>
    from flask_sqlalchemy import SQLAlchemy
  File "/usr/local/lib/python3.5/site-packages/flask_sqlalchemy/__init__.py", line 18, in <module>
    import sqlalchemy
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/__init__.py", line 9, in <module>
    from .sql import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/__init__.py", line 8, in <module>
    from .expression import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/expression.py", line 34, in <module>
    from .functions import func, modifier, FunctionElement, Function
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/functions.py", line 11, in <module>
    from . import sqltypes, schema
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
  File "<frozen importlib._bootstrap_external>", line 763, in get_code
  File "<frozen importlib._bootstrap_external>", line 816, in get_data
OSError: [Errno 14] Bad address

दोहराने के लिए, मैं इसे स्थानीय रूप से बिना डॉकटर के नहीं देखता। मैं इसे स्थानीय रूप से डॉकर के साथ नहीं देखता। यह, और टाइमआउट मुद्दे, केवल डॉकर/एडब्ल्यूएस/ईएलबी स्टैक (मेरे लिए) में स्पष्ट रूप से बन जाते हैं।

@tilgovi एक चीज जो मैंने शुरू में गलत की थी (जैसा कि ऊपर पोस्ट किए गए स्निपेट में देखा जा सकता है) यह है कि मेरे पास टाइमआउट गलत तरीके से 10 सेकंड पर सेट था। इसे 75 सेकंड में बदलने के बाद कार्यकर्ता टाइमआउट की संख्या काफी कम हो गई, शायद प्रति दिन एक जोड़े। पूर्णता के लिए यह सटीक कमांड है जिसका उपयोग मैं अपना ऐप शुरू करने के लिए कर रहा हूं:

gunicorn -k gevent --timeout 90 --keep-alive 75 --paste /etc/jzoo/app.ini "$@"

.ini फ़ाइल इस तरह दिखती है:

[DEFAULT]
sqlalchemy.url = postgresql://XXXX

[app:main]
use = egg:jzoo.api.admin

[server:main]
use = egg:gunicorn#main
bind = 0.0.0.0:5000
workers = 4
preload_app = true
loglevel = warning

# Logging configuration
[loggers]
keys = root,sqlalchemy,alembic,jzoo

# .. more logging configuration

यातायात की मात्रा एक कारक प्रतीत नहीं होती है - मैं इसे हमारे क्यूए वातावरण में देख रहा हूं जो केवल बहुत कम यातायात देखता है।

यह देखते हुए कि ऐसा कितनी बार होता है, मैं सोच रहा हूं कि क्या यह ऐप रीस्टार्ट से संबंधित हो सकता है?

मुझे कुछ ऐसी ही समस्या है। कुछ जांच के बाद, मुझे लगता है कि यह शायद नेटवर्क कनेक्शन त्रुटि है, न कि गनिकोर्न की।

यहाँ मेरा सेटअप है:

• Postgresql सर्वर EC2 पर Docker पर चलता है। डॉकर छवि आधिकारिक पोस्टग्रेज 9.6 है।
• ऐप सर्वर ईसी 2 के बाहर एक वीएम में डॉकर पर चलता है। डॉकर छवि आधिकारिक अजगर 3.6 है।
• AWS सुरक्षा समूह में केवल पोर्ट 5432 / tcp खोला जाता है।

मजेदार बात यह है कि ऐप सर्वर से सर्वर पोस्टग्रेज करने के लिए अधिकांश अनुरोध ठीक थे, एक को छोड़कर। ऐसा लगता है कि क्वेरी हमेशा के लिए चलती है, जो गनिकोर्न कार्यकर्ता का समय समाप्त कर देती है।

अगर मैं स्थानीय रूप से ऐप का उपयोग करता हूं तो समस्या दूर हो जाती है।

अगर मैं ऐप सर्वर को डॉकराइज़ नहीं करता तो समस्या भी दूर हो जाती है।

मेरा अस्थायी सुधार एडब्ल्यूएस सुरक्षा समूह सेटिंग के माध्यम से ऐप सर्वर और पोस्टग्रेज सर्वर के बीच सभी कनेक्शन को खोलता है। अब सब कुछ फिर से ठीक काम करता है।

मेरा अनुमान है कि पायथन कंटेनर और एडब्ल्यूएस के बीच एक कनेक्शन समस्या है। मैं एडब्ल्यूएस लॉग स्ट्रीम को अच्छी तरह से जांचने के बाद अपडेट करूंगा।

शुक्रिया!! ईएलबी और इंस्टेंस प्रोटोकॉल को एचटीटीपी से टीसीपी में बदलना ठीक काम करता है

समस्या AWS के लिए विशिष्ट नहीं लगती है, लेकिन Gunicorn के साथ संयुक्त होने पर Docker को ही। मैं इसे gevent साथ भी देखता हूं, कम से कम हमारे उत्पादन परिवेश में।

@tilgovi इस त्रुटि को फिर से बनाने के लिए यहां एक सरल ऐप है (हर अब और फिर, पैटर्न नहीं मिला है, शायद आप शायद):

app.py:

import falcon


class HelloResource:
    def on_get(self, req, resp):
        resp.media = {'info': 'hello world'}


app = falcon.API()
app.add_route('/', HelloResource())

डॉकरफाइल:

FROM python:3.6
WORKDIR /code
RUN pip install gunicorn falcon
COPY app.py .
CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

चलाने के लिए: docker build -t gunicorn-and-docker . && docker run -p 8000:8000 -it --rm gunicorn-and-docker

लॉग इस तरह दिखेंगे (कम से कम मेरे लिए macOS सिएरा पर Docker 17.06.2-ce-mac27 (19124) का उपयोग करके):

[2017-09-23 22:31:00 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-09-23 22:31:00 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2017-09-23 22:31:00 +0000] [1] [INFO] Using worker: sync
[2017-09-23 22:31:00 +0000] [9] [INFO] Booting worker with pid: 9
[2017-09-23 23:22:45 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-09-23 23:22:45 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-09-23 23:22:45 +0000] [11] [INFO] Booting worker with pid: 11
[2017-09-23 23:39:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-09-23 23:39:46 +0000] [11] [INFO] Worker exiting (pid: 11)
[2017-09-23 23:39:46 +0000] [13] [INFO] Booting worker with pid: 13
[2017-09-23 23:41:10 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:13)
[2017-09-23 23:41:10 +0000] [13] [INFO] Worker exiting (pid: 13)
[2017-09-23 23:41:10 +0000] [15] [INFO] Booting worker with pid: 15
[2017-09-23 23:42:27 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:15)
[2017-09-23 23:42:27 +0000] [15] [INFO] Worker exiting (pid: 15)
[2017-09-23 23:42:27 +0000] [17] [INFO] Booting worker with pid: 17
[2017-09-23 23:43:44 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)
[2017-09-23 23:43:44 +0000] [17] [INFO] Worker exiting (pid: 17)
[2017-09-23 23:43:44 +0000] [19] [INFO] Booting worker with pid: 19
[2017-09-24 18:37:12 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:19)
[2017-09-24 18:37:12 +0000] [19] [INFO] Worker exiting (pid: 19)
[2017-09-24 18:37:12 +0000] [21] [INFO] Booting worker with pid: 21
[2017-09-24 19:49:20 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:21)
[2017-09-24 19:49:20 +0000] [21] [INFO] Worker exiting (pid: 21)
[2017-09-24 19:49:20 +0000] [23] [INFO] Booting worker with pid: 23
[2017-09-24 19:50:37 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:23)
[2017-09-24 19:50:37 +0000] [23] [INFO] Worker exiting (pid: 23)
[2017-09-24 19:50:37 +0000] [25] [INFO] Booting worker with pid: 25
[2017-09-24 20:25:48 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-09-24 20:25:48 +0000] [25] [INFO] Worker exiting (pid: 25)
[2017-09-24 20:25:48 +0000] [27] [INFO] Booting worker with pid: 27

नमस्ते,

मैं हाल ही में एक ही समस्या से टकरा गया हूं।
मेरे मामले में (ECS + gunicorn 19.7.1 + Django 1.11.5) मैं (जाहिरा तौर पर) कार्य परिभाषा (128 से 256mb तक) में कंटेनर को समर्पित मेमोरी की मात्रा को बढ़ाकर इसे हल करने में कामयाब रहा।
अब तक कोई और त्रुटि नहीं है। अगर ऐसा दोबारा होता है तो मैं यहां रिपोर्ट करूंगा।

यहां कोरस में थोड़ा सा जोड़ना, लेकिन मैं इसे केवल गीवेंट पर स्विच करके हल करने में सक्षम था।

मैंने बिना किसी किस्मत के सिंक वर्कर के साथ टाइमआउट को 90 तक बढ़ाने और 75 तक रखने की कोशिश की।

साथ ही, दिलचस्प बात यह है कि इस परिदृश्य में मेरा ईएलबी केवल टीसीपी स्तर अग्रेषण कर रहा है, न कि HTTP।

ठीक है, मुझे कुछ संदर्भ मिले जो इसे समझाते हैं। [1]

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

[१] https://cloudavail.com/2013/12/21/aws-elb-pre-open-connection-expose-part-1/

यदि आप इसका अनुभव कर रहे हैं और gevent/eventlet/asyncio का उपयोग नहीं करना चाहते हैं, तो मैं थ्रेडेड वर्कर पर स्विच करने की सलाह देता हूं ( --threads सेटिंग प्रदान करें)।

@tilgovi यदि आप ऊपर दिए गए मेरे उदाहरण को देखें तो यह समस्या

@jmagnusson आपका उदाहरण (इस टिप्पणी से: https://github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187) सिंक वर्कर का उपयोग कर रहा है।

[२०१७-०९-२३ २२:३१:०० +००००] [१] [सूचना] कार्यकर्ता का उपयोग करना: सिंक

@tilgovi सच है, लेकिन मैंने उत्पादन में gevent कार्यकर्ता के साथ भी इसका अनुभव किया है। मैं gevent के साथ प्रजनन के लिए कुछ समय निकालने की कोशिश करूंगा।

यह सिर्फ मैं (मूर्खतापूर्ण) हो सकता है, लेकिन ईसी 2 सुरक्षा समूह में -> इनबाउंड नियम, मेरे पास केवल एक आईपी (मेरा आईपी: XX.XX.XX.XX) की अनुमति देने के लिए पोर्ट 5000 (यहां गनिकोर्न) के लिए एक कस्टम टीसीपी नियम है। /32), इसे सभी आईपी में बदलने से मदद मिलेगी।

मैं भी परेशानी से मिलता हूं।

[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:03 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:04 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:05 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:06 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:07 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:08 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:09 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [INFO] worker pid 24358 notify
[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:38:41 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:42 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:43 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:44 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:45 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:46 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:47 +0800] [24381] [INFO] worker pid 24381 notify
......
[2018-01-02 16:48:20 +0800] [24381] [INFO] worker pid 24381 notify
[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. 

मैंने डीबग लॉग worker pid {WORKER_PID} notify जोड़ा।

डिबग लॉग के अनुसार,

1. केवल अगर कार्यकर्ता प्रक्रिया को एक अनुरोध प्राप्त होता है, तो अधिसूचना जारी नहीं होगी। तो, अनुरोध हैं या नहीं, मास्टर 30 के बाद कार्यकर्ता प्रक्रिया को मार देगा।
2. एक बार पहला अनुरोध बंद होने के बाद, मैंने अभी दूसरा अनुरोध भेजा, लेकिन दूसरा अनुरोध अवरुद्ध है और कोई प्रतिक्रिया नहीं है। जब 30 का समय समाप्त हो गया, तो कार्यकर्ता प्रक्रिया समाप्त हो गई और नई कार्यकर्ता प्रक्रिया दूसरे अनुरोध का जवाब देगी। इसके बाद फिर से सर्वर हैंग कर दिया गया है।
3. जब कार्यकर्ता प्रक्रिया को लटका दिया गया है, तो उसे मास्टर से संकेत प्राप्त नहीं होगा, जैसे SIGTERM । जब सुंदर समय समाप्त हो गया, तो मास्टर इसे SIGKILL जबरदस्ती मार देगा।

Python: 3.6.3
Gevent: 1.2.2
Gunicorn: 19.7.1
RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

सूचना: जब मैं कार्यकर्ता के रूप में eventlet उपयोग करता हूं, तो यह ठीक है।

मैं इस मुद्दे को बंद करने जा रहा हूं क्योंकि मुझे लगता है कि यह पुराना है। जैसा कि सबसे अच्छा मैं निर्धारित कर सकता हूं, देखा गया व्यवहार एडब्ल्यूएस क्लासिक लोड बैलेंसर्स के प्री-ओपन ऑप्टिमाइज़ेशन करने के कारण है। यह अनुकूलन केवल क्लासिक लोड बैलेंसर्स द्वारा किया जाता है, दस्तावेज़ के अनुसार इस ब्लॉग पोस्ट में प्रलेखित है, AWS से प्री-ओपन ऑप्टिमाइज़ेशन को अक्षम करने या Gunicorn के लिए वर्कर टाइमआउट बढ़ाने का अनुरोध करना संभव है।

@tilgovi FWIW मैंने इसे ALB के साथ देखा। मैंने कभी भी क्लासिक लोड बैलेंसर्स का उपयोग नहीं किया है।

@tilgovi मैंने भी इसे बार-बार

@tilgovi मैं इससे मिला। मैंने कभी एडब्ल्यूएस का उपयोग नहीं किया है।

किसी को इसे पुन: पेश करने में मदद करनी है, और इसे डीबग करने का प्रयास करना है। मैं इसे एएलबी के साथ पुन: पेश नहीं कर सकता और मैं नहीं देख सकता कि इसे एडब्ल्यूएस के बाहर कैसे पुन: पेश किया जाए।

@xgfone आप अपना खुद का मुद्दा खोलना चाह सकते हैं, इस मुद्दे का शीर्षक "डॉकर + एडब्ल्यूएस" है

क्या किसी ने एडब्ल्यूएस लोड बैलेंसर्स के साथ इसका अनुभव किया लेकिन डॉकर के बिना? मैं थोड़ा भ्रमित हूँ, मुझे स्वीकार करना होगा :)

मेरी धारणा यह थी कि यह मुद्दा वास्तव में डॉकर से अधिक संबंधित था - कम से कम मेरे पास मेरी स्थानीय मशीन पर डॉकर के अंदर कई गनिकोर्न सिंक वर्कर्स चलाने वाले समान मुद्दे थे।

इस कॉन्फिग ने उबंटू और आरएचईएल मशीनों पर डॉकर के बिना ठीक काम किया, दोनों नंगे धातु और डिजिटल महासागर में वर्चुअलाइज्ड:

workers = 2
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

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

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

अगर आपको लगता है कि यह इस धागे से असंबंधित है, तो मुझे इसे यहां से हटाकर कहीं और रखने में खुशी हो रही है ;-)

बेस्ट, बोरिस

@tilgovi

यह त्रुटि arbiter.py, murder_workers । murder_workers फ़ंक्शन तब लागू होता है जब SIG_QUEUE खाली होता है (उदाहरण के लिए सिग्नल की प्रतीक्षा करते समय)।

फिर यह देखने के लिए जांच करेगा कि टाइमआउट हर सेकेंड तक पहुंच गया था या नहीं। जीने के लिए शेष समय हमेशा 1 सेकंड या 0 सेकंड था क्योंकि गीवेंट कार्यकर्ता एक नियंत्रित अनंत लूप में होता है जबकि self.alive ने self.notify आह्वान किया जो एक फ़ाइल को अपडेट करता है। फ़ाइल के अपडेट हैं कि आखिरी सक्रिय समय होने पर गनिकोर्न कैसे जांच कर रहा है।

इस प्रकार, murder_workers फ़ंक्शन में लाइव चेक करने का एकमात्र तरीका विफल हो जाता है (उदाहरण के लिए यह बहुत लंबा निष्क्रिय हो गया है) यह है कि यदि gevent जीवित संपत्ति बदल दी गई थी। निम्नलिखित विधियाँ इसे नियंत्रित करती हैं:

handle_quit
handle_request (यदि अधिकतम अनुरोध प्राप्त हुए थे, तो डिफ़ॉल्ट रूप से यह अनुरोधों की संख्या का 2^64 बिट या 32-बिट ओएस होने पर 2^32 है)
changed (यदि कोई फ़ाइल बदली गई थी तो पुनः लोडर से मंगाई गई)
handle_exit
handle_abort

इन विधियों को संकेतों से बुलाया जाता है

handle_quit - सिग्क्विट, सिगिनट
handle_exit - सिगटरम
handle_abort - सिगाबर्ट

इस प्रकार, 2 संभावित समस्याएं हैं जो मुझे दिखाई देती हैं:

1. सूचना विधि अपने लूप के दौरान फ़ाइल को अद्यतन करने में सक्षम नहीं है
2. सिग्नल गलत तरीके से भेजा जा रहा है

मुझे लगता है कि अधिक संभावित कारण दूसरा है। संकेतों का मुख्य स्रोत आर्बिटर फ़ाइल के भीतर है और इन अपवादों द्वारा ट्रिगर किया गया है:

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception (अनियंत्रित अपवाद)

मुझे लगता है कि स्टॉपइटरेशन अपवाद सबसे अधिक संभावना है कि अपराधी ने async.py फ़ाइल में req = six.next(parser) पर ट्रिगर किया। ऐसा प्रतीत होता है कि यह अगली विधि सिर्फ parser.next() को लागू कर रही है।

Parser.next() निम्नलिखित 2 शर्तों पर StopIteration अपवाद उठाता है:

1. If the message indicates it should close:
    1. http Connection close (and keep-alive false)
    2. WSGI - request method not HEAD, response_length is none, and status code is > 200 (but not 204, or 304)
2. If self.mesg (Request message) is falsey

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

मैं इसे फिर से खोलूंगा और इन संयोजनों का परीक्षण करने का प्रयास करूंगा:

• डॉकर लोकल
• क्लासिक लोड बैलेंसर के साथ डॉकर एडब्ल्यूएस
• एप्लिकेशन लोड बैलेंसर के साथ डॉकर एडब्ल्यूएस

अगर कोई ऐसा रेपो बनाना चाहता है जो इसे पुन: पेश कर सके, तो यह मददगार होगा, लेकिन मैं शायद इस सप्ताह के अंत में ऐसा कर सकता हूं।

मुझे यह समस्या हो रही है और मैं AWS का उपयोग नहीं कर रहा हूँ।
मेरा सेटअप एनजीआईएनएक्स -> डॉकर कंटेनर (जीवेंट वर्कर्स + Django के साथ गनिकोर्न) है। मैं Gunicorn के डिफ़ॉल्ट टाइमआउट का उपयोग कर रहा हूं।

कोई सुझाव?

धन्यवाद।

हाय @ डेविडमिर ,
मुझे एक ही समस्या थी, कार्यकर्ता प्रकार बदलने से मदद नहीं मिली। एकाधिक धागे वाले एक सिंक कार्यकर्ता पर स्विच करने से मेरे लिए चाल चल रही है:

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

बेस्ट, बोरिस

हालांकि यह ऊपर कुछ उल्लेख किया गया है, इस मुद्दे के अपने स्वयं के डिबगिंग से स्पष्ट करने के लिए, इनमें से कुछ स्मृति त्रुटियों से बाहर हैं; विशेष रूप से अगर इसे कार्यकर्ता की गिनती को 1 में बदलकर हल किया जाता है।

यह डॉकर पर विशेष रूप से समस्याग्रस्त है यदि आपके पास अपने कॉन्फ़िगरेशन में ऐसा कुछ है:

workers = multiprocessing.cpu_count() * 2 + 1

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

हालांकि यह आवेदन से आवेदन में भिन्न होता है, मेरे अंगूठे का नियम एक दुबला विन्यास में प्रति कार्यकर्ता 256 मेग्स और सुरक्षित होने के लिए 512 है।

क्लासिक ईएलबी HTTPS => HTTP Gunicorn सिंक वर्कर्स का उपयोग करके एक ही समस्या का सामना करना पड़ा

जैसा कि अन्य ने उल्लेख किया है कि डिफ़ॉल्ट सिंक कार्यकर्ता के बजाय -k gevent तर्क का उपयोग करना सबसे आसान फिक्स था।

हमने पूरी तरह से नए डॉकर कंटेनर (एएलबी के पीछे ईसीएस में होस्ट किया गया) के लिए एक ही समस्या को फिर से देखा, और एक पूरी तरह से अलग (लेकिन पिछली बार, स्पष्ट रूप से होना चाहिए) समाधान पाया: क्लाउडफॉर्मेशन में कंटेनर को अधिक मेमोरी आवंटित करें टेम्पलेट।

हम पिछले साल इस मुद्दे से पीड़ित थे और धूम्रपान बंदूक मूल कारण कभी नहीं मिला, लेकिन आज रात मैंने इसे एक नए कंटेनर पर देखा, और यह देखा कि कंटेनर हमारे द्वारा आवंटित सभी मेमोरी को खा रहा था। जैसे ही मैंने आवंटन को दोगुना कर दिया, कंटेनरों ने इस त्रुटि को फेंकना बंद कर दिया (इससे पहले कि मैं इससे अधिक आवंटित करता, अंततः उपभोग करेगा):
https://github.com/hackoregon/civic-devops/issues/157

यहां एक समान समस्या का सामना करना पड़ रहा है। कोड उतना ही सरल है

while true:
      sleep(10)

कार्यकर्ता की मृत्यु हो सकती है (इस कोड के बिना हमारी तैनाती सामान्य है)
यह बहुत हैरान करने वाला है, b/c sleep पहले से ही दिल की धड़कन भेज देना चाहिए।

भी पहले से ही gevent में बदल गए हैं, मदद नहीं की। आश्चर्य है कि क्या किसी के पास कोई विचार है?

नमूना आउटपुट:
[2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:521) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:522) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:523) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:524) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:525) [2018-06-16 16:00:16 +0000] [524] [INFO] Worker exiting (pid: 524) [2018-06-16 16:00:16 +0000] [521] [INFO] Worker exiting (pid: 521) [2018-06-16 16:00:16 +0000] [523] [INFO] Worker exiting (pid: 523) [2018-06-16 16:00:16 +0000] [522] [INFO] Worker exiting (pid: 522) [2018-06-16 16:00:16 +0000] [525] [INFO] Worker exiting (pid: 525) [2018-06-16 16:00:17 +0000] [531] [INFO] Booting worker with pid: 531 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [136] [DEBUG] 1 workers [2018-06-16 16:00:17 +0000] [532] [INFO] Booting worker with pid: 532 [2018-06-16 16:00:17 +0000] [533] [INFO] Booting worker with pid: 533 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [534] [INFO] Booting worker with pid: 534 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [535] [INFO] Booting worker with pid: 535 [2018-06-16 16:00:17 +0000] [136] [DEBUG] 5 workers

यहां के पानी को गंदा करने के लिए क्षमा करें, लेकिन मैं अपना अनुभव साझा करना चाहता हूं, मेरा स्टैक HTTP ELB > Nginx > gunicorn/gevent on EC2 , सर्कसड का उपयोग करके प्रक्रियाएं चलती हैं

मुझे मिली समस्या यह थी कि मेरे django ऐप को लोचदार-एपीएम के साथ स्थापित करने के बाद मेरी HTTP स्वास्थ्य जांच लगभग तुरंत विफल हो जाएगी और कुछ सेकंड के बाद गनिकोर्न अनुत्तरदायी हो जाएगा।

मैंने अपने स्वास्थ्य जांच के खिलाफ कुछ स्थानीय wrk बेंचमार्क की कोशिश की, सिंक को 1-5 श्रमिकों के लिए लगभग 300rps मिल रहा था, लेकिन gevent को 1rps मिलेगा। एपीएम को बंद करने से लगभग ५० आरपीएस तक जीवेंट लाया गया और सिंक के लिए नगण्य वृद्धि हुई।

वालग्रिंड पर कोई अजीब स्मृति उपयोग नहीं देखा, आमतौर पर गनिकोर्न के लिए लगभग 4 एमबी और प्रति कार्यकर्ता 40 एमबी

वैसे भी, gunicorn 19.6.0 > 19.9.0 और gevent 1.2.2 > 1.3.6 को अपडेट करने से मुझे एक रॉक स्टीडिंग ELB स्वास्थ्य जांच फिर से मिल रही है और स्थानीय स्तर पर ~300rps। जब तक मेरे पास कुछ एपीएम लॉगिंग नहीं थी, तब तक मैं जानबूझकर गनिकोर्न/गीवेंट को अपडेट नहीं कर रहा था, ऐसा लगता है कि ऐसा करने से कुछ गंभीरता आई है। गीवेंट को अपडेट करने से सबसे ज्यादा बढ़ावा मिला, लेकिन फिर गनिकोर्न को अपडेट करने से 10% या तो और जुड़ गया।

अभी तक चैंजों को अधिक विस्तार से नहीं देखा है, शायद अनुरक्षक सबसे संभावित कारण पर प्रकाश डाल सकते हैं?

वैसे भी, gunicorn 19.6.0 > 19.9.0 और gevent 1.2.2 > 1.3.6 को अपडेट करने से मुझे फिर से एक रॉक स्टीडिंग ELB स्वास्थ्य जांच मिल रही है और स्थानीय स्तर पर ~300rps... अपडेट करने से gevent को सबसे अधिक बढ़ावा मिला है।

वाह, यह बहुत अच्छा है!

समापन मुद्दा। थोड़ी देर से कोई गतिविधि नहीं।

FWIW, मुझे अभी भी यह समस्या हो रही है @benoitc :-\

Django 2.1.5
गनिकोर्न 19.8.1
गीवेंट 1.2.2
AKS 1.15.7 5 नोड्स के साथ (मानक B2's - 2 vcores और 2GB मेमोरी)
3 पॉड/डॉकर कंटेनर, जिनमें से प्रत्येक में है:

    spec:
      containers:
        - name: web-container
          command: ["newrelic-admin"]
          args: [
              "run-program",
              "gunicorn",
              "--limit-request-field_size=16380", # limit also specified in nginx
              "--workers=3", # (2 x vcpu) + 1. vcpu < limit defined in resources
              "-k=gevent",
              "-b=0.0.0.0:8000",
              "ourapp.wsgi",
              "--timeout 60",
              "--log-level=debug",
            ]
          resources:
            requests:
              memory: "200Mi"
              cpu: "250m"
            limits:
              memory: "3000Mi"
              cpu: "2000m"

EKS, Nginx और NLB के साथ यहाँ भी यही समस्या है।

@salmicrosoft @sinkr ठीक है, लेकिन कृपया एक नया मुद्दा खोलें और आपके पास कोई भी लॉग प्रदान करें जो हमें यह पता लगाने में मदद कर सके कि क्या होता है। आपका ऐप भी क्या करता है? क्या आपका कोई लंबा अनुरोध है?

ईसीएस फारगेट पर मेरा एक ही मुद्दा था, लेकिन यह डॉकर/gunicorn.conf.py में गलत रखरखाव/समयबाह्य सेटिंग्स से संबंधित था, यह था
रखवाले (सेट नहीं)
समय समाप्त = २

इसे ठीक करने से पहले यह स्थानीय रूप से चलने वाले कंटेनर के साथ अच्छी तरह से काम करता है, लेकिन ECS Fargate पर विफल रहा, अब यह दोनों वातावरणों पर सही ढंग से काम करता है।