Gunicorn: Waktu habis pekerja sinkronisasi Gunicorn di buruh pelabuhan + AWS

hrmmm dari log di atas saya dapat melihat bahwa waktu tidak pernah berubah. saya akan memeriksa

Terima kasih, saya menghargainya!

Saya mungkin terpengaruh oleh bug ini.

Saya menjalankan gunicorn di dalam gambar Docker di AWS (Elastic Beanstalk + EC2 Container Service).
Ada batas waktu pekerja konstan yang mulai terjadi segera setelah inisialisasi, dan hanya saat menjalankan image Docker di AWS.
Permintaan HTTP yang sama terkadang membutuhkan waktu beberapa ms, terkadang 20-30 detik. Tidak masalah apakah itu untuk halaman yang tidak ada, halaman string "Hello world" sederhana yang tidak diautentikasi atau halaman yang mengambil catatan dari database.

Detail tambahan :

• Versi Gunicorn : 19.5.0 dan 19.6.0.
• Gambar Docker Dasar : python:3.4 ( OS : Debian Jessie)
• Versi Docker : 1.9.1 (dikelola oleh Amazon ECS), OS : Amazon Linux AMI 2016.03 (dikelola oleh Amazon EB).
• Kerangka aplikasi web : Django versi 1.9.6 dan 1.9.7.

Lingkungan _not_ terpengaruh :

• Mesin lokal , baik _inside_ dan _outside_ wadah Docker. OS : Ubuntu 16.04 LTS, Docker : 1.11.2.
• Heroku ( OS : Ubuntu 14.04 LTS)

Log kontainer Amazon :

[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)
(...)

`

Terima kasih.

Saya melihat ini juga. Kecurigaan saya adalah Elastic Load Balancer. Kami dulu menggunakan paste di perusahaan sebelumnya dan ini menyebabkan masalah dengan ELB. Saya percaya itu menggunakan kembali koneksi entah bagaimana dan ini menyebabkan cegukan di paste .

Saya sekarang dalam pekerjaan baru di mana kami menggunakan gunicorn dan semuanya baik-baik saja sampai kami mulai menempatkan server di belakang ELB, aplikasi web sekarang sering sangat tidak responsif dan tampaknya hang.

Coba gunakan pekerja gevent sebagai gantinya, ini telah memecahkan masalah bagi saya.

Jadi, apakah ini masalah dengan ELB yang menjaga koneksi tetap hidup dan mengikat pekerja sinkronisasi? Itu menurut saya sangat aneh karena kami sengaja memberi sinyal bahwa koneksi harus ditutup dengan pekerja sinkronisasi: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L168

Kami bisa menutup koneksi dengan sengaja. Jika ada yang ingin menguji pemindahan panggilan client.close() menjadi tanpa syarat, itu mungkin tes yang menarik: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L199

Anda juga dapat memastikan bahwa batas waktu idle pada ELB lebih rendah daripada batas waktu pekerja, sebagai pemeriksaan kewarasan cepat bahwa ini adalah penyebab masalah: http://docs.aws.amazon.com/elasticloadbalancing/latest/ classic/config-idle-timeout.html

@tilgovi hal elb adalah tebakan terbaik saya saat ini, karena a) itu terjadi hanya jika gunicorn berada di belakang ELB dan b) masalah diperbaiki dengan menggunakan gevent pekerja. Tapi sekali lagi, siapa yang tahu..

itu terjadi hanya di belakang ELB, dan jika protokol HTTP atau HTTPS diatur pada ELB.
Jika Anda mengubah protokol ke TCP atau SSL, masalahnya akan hilang.
Adakah yang tahu cara memperbaikinya masih menggunakan pekerja sinkronisasi? Saya menggunakan perbaikan yang saya jelaskan (TCP bukan HTTP) sampai sekarang, ketika saya akan memantau log akses dan melihat header X-Forwarded-For, yang diaktifkan hanya untuk HTTP/HTTPS di ELB :)

Aneh, hanya untuk memastikan kita berada di halaman yang sama, ini berarti ada semacam optimasi saat menggunakan opsi HTTP/HTTPS di ELB? Dan pengoptimalan ini menyebabkan masalah dengan pekerja sinkronisasi?

@ecs Saya pikir dalam kasus penyeimbang beban HTTP/HTTPS menggunakan kembali koneksi TCP yang sama, yang disimpan oleh ELB hidup lama - semacam itu. Tapi itu tidak menjelaskan mengapa pekerja gevent berfungsi dengan baik ... (walaupun saya belum menguji gevent, baca saja dari komentar ini)

Btw, pasti ada banyak faktor (versi gunicorn, kelas pekerja, di dalam buruh pelabuhan atau tidak, protokol ELB) yang dapat mempengaruhi, jadi mungkin bagus jika seseorang akan menguji dan mengkonfirmasi bahwa protokol TCP pada ELB bekerja tidak seperti HTTP. Saya sedang menguji pada buruh pelabuhan yang dihosting di Ubuntu 14.04 dan gunicorn versi 19.3.0

Saya memiliki masalah yang sama:
[2016-10-03 12:13:17 +0000] [6] [KRITIS] TIMEOUT PEKERJA (pid:16)
[2016-10-03 12:13:17 +0000] [16] [INFO] Pekerja keluar (pid: 16)
[2016-10-03 12:13:17 +0000] [6] [KRITIS] TIMEOUT PEKERJA (pid:20)
[2016-10-03 12:13:17 +0000] [20] [INFO] Pekerja keluar (pid: 20)
[2016-10-03 12:13:17 +0000] [33] [INFO] Boot pekerja dengan pid: 33

Pengaturan saya.

Saya menggunakan kube-aws untuk menyiapkan cluster kubernetes dengan core-os di AWS: https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws

Saya memiliki aplikasi python menggunakan gunicorn dan menyinkronkan pekerja. Layanan untuk mereka menggunakan penyeimbang beban HTTPS dengan sertifikat situs saya. Semua pekerja dianggap habis waktu setelah waktu tunggu default 30-an tampaknya. Mereka akhirnya semua restart. Kubernetes akhirnya me-restart container ketika keluar.. restart ini terjadi terus menerus. Seseorang di atas menyebutkan bahwa gevent memecahkan masalah saya dapat mencobanya tetapi saya benar-benar ingin memahami mengapa ini terjadi.

Kami juga melihat masalah ini saat ini, saya akan mencoba dan memposting lebih banyak detail ketika saya mendapat kesempatan. Ini terkait dengan pekerja sinkronisasi karena pindah ke gevent memang menyelesaikan masalah. Ini ada di AWS dengan ECS dan ELB.

Punya masalah aneh yang sama juga dengan salah satu aplikasi kami. Mengubah pendengar dari HTTP ke tcp memang memecahkan masalah.

adakah yang bisa memberi saya cara langkah demi langkah untuk mereproduksi masalah? (langkah konfigurasi dan semacamnya) Atau setidaknya arahkan saya ke cara sederhana untuk mengatur lingkungan itu :) Saya akan melihatnya minggu ini.

Mengandalkan HTTP untuk penyeimbang seperti itu umumnya memerlukan penanganan keep-alive di belakang, (kecuali untuk tcp) jadi apa pun yang menggunakan pekerja sinkronisasi mungkin menjadi masalah hingga pekerja sinkronisasi akan diperbarui untuk dukungannya.

Pokoknya beri tahu saya.

Cukup siapkan aplikasi Flask dasar dan jalankan dengan gunicorn dengan pekerja sinkronisasi di dalam buruh pelabuhan di AWS, dengan penyeimbangan beban HTTP dan konfigurasi dari atas:

Menggunakan gunicorn 19.4.5 di dalam gambar buruh pelabuhan, yang berjalan di Ubuntu 14.04 LTS di AWS, saya melihat batas waktu pekerja konstan saat dijalankan dengan >1 pekerja sinkronisasi dan periode batas waktu default 30 detik.

Anda tidak perlu membuat permintaan apa pun ke aplikasi, cukup pantau log dan Anda akan melihat waktu pekerja habis.

• Saya dapat mengkonfirmasi perilaku ini serta pendekatan dasar untuk mereproduksinya.
  
  
  
  • Perilaku tidak terbatas pada Docker melainkan pada pekerja sinkronisasi/pengaturan keepalive, sehingga Anda dapat mempertimbangkan untuk mengubah judul...
  
  
• Saya telah memodifikasi pengaturan keepalive untuk mengikuti apa yang dijelaskan di sini: https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ (bagian yang paling menarik adalah kutipannya dari dokumentasi AWS ELB) dan mendapati server tidak lagi menunjukkan perilaku ini.
• Selain itu saya juga telah mengubah ke kelas pekerja gthread dan menemukan hasilnya sangat dapat diterima hingga sekarang.

Saat ini saya menggunakan pekerja gevent dengan periode batas waktu 65 detik (batas waktu AWS ELB adalah 60 detik, AFAIK). Saya terkadang masih mengalami 504 kesalahan bahkan ketika hanya satu klien yang membuat permintaan, dengan 1 permintaan dalam penerbangan pada satu waktu, tetapi saya belum dapat menemukan alasannya.

@obi1kenobi Apakah Anda mencoba meningkatkan keepalive hingga melampaui opsi batas waktu ELB?

@lenucksi keepalive sudah lebih tinggi dari batas waktu ELB sebesar 5 detik - semoga jam server tidak terlalu banyak mendorong :)

Saya juga mengalami masalah ini saat menjalankan gunicorn 19.6 di dalam wadah Docker pada instance EC2 di belakang ELB (menggunakan protokol HTTP default untuk reverse-proxy ke instance EC2).

Seperti yang disarankan sebelumnya, menyetel kelas pekerja ke gevent menyelesaikan masalah ini untuk saya (di mana sebelumnya saya telah menggunakan kelas pekerja default sync ).

Saya akan mencoba dan mendokumentasikan contoh minimal untuk mereproduksi masalah.

Untuk menguatkan apa yang dikatakan orang lain, ELB tampaknya membuka koneksi ke instans EC2 dan menahannya agar tetap terbuka dengan cara mengunci gunicorn dari menangani permintaan tambahan.

Ketika koneksi yang ditahan-terbuka berakhir karena gunicorn mengatur waktu permintaan dari ELB, semua permintaan tertunda yang diantrekan di belakangnya juga gagal (termasuk pemeriksaan kesehatan ELB, menyebabkan instans dihapus dari ELB, membuat ini lebih sulit untuk di-debug ; ) ).

Gejala ini menunjukkan ini adalah duplikat dari apa yang telah diamati dalam masalah sebelumnya yang tidak terkait dengan Docker: https://github.com/benoitc/gunicorn/issues/588

@jelis Tahukah Anda jika ini terkait dengan beberapa konfigurasi kubernetes? Apakah masalah Anda terpecahkan?

Saya juga menggunakan ELB dengan penghentian SSL. Saya melihat ini di log saya:

[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

Pembaruan - Saya baru saja beralih dari gunicorn ke gevent ( http://flask.pocoo.org/docs/0.12/deploying/wsgi-standalone/#gevent ) dan masalahnya teratasi. Ini mengacu pada komentar saya di atas https://github.com/benoitc/gunicorn/issues/1194#issuecomment -283269046

Saya telah memalu masalah ini selama beberapa hari. Catatan semua orang di sini luar biasa, dan memberi kami sejumlah jalan untuk mengejar perbaikan/penyelesaian/mitigasi. (log pekerjaan saya ada di bug yang kami lacak di sini )

Saya baru saja mencoba penggunaan gevent dengan dorongan dalam jumlah pekerja dan itu tidak membantu kami sama sekali - bahkan secara mengejutkan membuatnya terlihat lebih buruk - kelima pekerja gevent meninggal pada saat yang sama, yang merupakan perilaku baru dari yang saya baca di atas:

[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

Ini mungkin beberapa kesalahan di pihak saya, dan perilakunya tidak sama dengan salah satu rekan proyek saya (dengan basis kode yang serupa tetapi tidak identik dalam penerapan AWS/CloudFormation/ALB/ECS yang hampir identik). Namun saya pikir saya akan melaporkannya jika itu menginspirasi wawasan baru tentang interaksi antara ALB, ECS, Docker, dan gunicorn.

Saya memiliki pengaturan serupa (convox menjalankan ELB->ECS Docker Container->Gunicorn->Django) dan saya dapat mengonfirmasi bahwa perubahan konfigurasi berikut tampaknya telah membantu:

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

Saya mengatur batas waktu idle ELB saya menjadi 60 detik.

Sebelum mengubah pengaturan ini, saya menggunakan default untuk keepalive, timeout, dan pekerja sinkronisasi.

Menariknya, masalah ini mulai dipamerkan pada pukul 4 pagi UTC 10 April. Aplikasi telah berjalan dengan baik tanpa perubahan apa pun sejak Kamis sebelumnya.

hanya menumpuk, tidak ada buruh pelabuhan, tetapi instance telanjang aws mengalami masalah yang sama di belakang ELB. berfungsi NP di osx, tetapi ubuntu16 dengan masalah ELB yang sama muncul. gevent kelas pekerja tampaknya memperbaikinya [untuk saya].

Adakah yang bisa memeriksa ini di utas ini?
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

@erikcw tampaknya telah menemukan solusi ini untuk bekerja. Saya ingin menutup masalah ini. Jika ada yang bisa mereproduksi ini setelah menaikkan batas waktu pekerja Gunicorn dan batas waktu keepalive, tolong katakan demikian.

Atau, turunkan batas waktu idle untuk ELB.

Tidak bisakah klien di alam liar (atau klien jahat) bertindak seperti ELB dan menyebabkan masalah yang sama?

@ enam8 ya. ELB juga tidak melindungi Anda dari ini. Dokumentasi membahas ini: http://docs.gunicorn.org/en/latest/design.html#choosing -a-worker-type

Beberapa orang tidak peduli dengan ancaman ini dan hanya ingin menggunakan Gunicorn, di pinggir atau di belakang ELB. Masalah yang dibahas di sini adalah timeout pekerja yang disebabkan oleh ELB itu sendiri. Saya ingin memberikan konfigurasi yang disarankan yang membuat gunicorn bekerja di belakang ELB dengan pekerja sinkronisasi dan tanpa proxy terbalik tambahan.

Saya mencoba solusi @erikcw juga dengan mengubah doa gunicorn menjadi:

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

Sayangnya itu tidak membantu:

[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)

Saya memiliki aplikasi yang berjalan di ECS di belakang ALB dengan pekerja sinkronisasi Gunicorn. Saya belum melihat masalah apa pun.

Adakah yang bisa memberikan penyebaran yang dapat direproduksi?

menumpuk, juga. melihat masalah ini menggunakan Kubernetes di AWS dengan ELB. Saat ini memiliki 8 pekerja berjalan. Per https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ , kita akan naik keepalive , dan per utas ini akan mencoba untuk menggunakan pekerja gevent sebagai gantinya. Tetapi saat ini, yang gagal adalah beberapa tes kinerja untuk panggilan api yang seharusnya tidak memblokir / menyebabkan batas waktu sendiri. ingin tahu apa yang terjadi di sini dengan sync pekerja. bahkan jika kami membuatnya bekerja sesuai dengan beberapa pedoman bagus di utas ini, kami ingin sedikit lebih percaya diri tentang apa yang terjadi sebelum menerapkan ke produksi.

Mengatur --worker-class ke --worker-class gevent berhasil untuk saya. Terima kasih atas komentar dan bantuannya!

@wichert ini sangat aneh. Dengan pekerja gevent, pekerja harus memberi tahu arbiter tentang kehidupan mereka di greenlet terpisah dari koneksi apa pun. Pengaturan keep-alive Anda seharusnya tidak mempengaruhi ini sama sekali. Ada yang salah dengan aplikasi Anda, sehingga gevent tidak berfungsi seperti yang dirancang, atau sesuatu tentang penyiapan bermasalah yang mungkin umum terjadi pada skenario lain ini.

Tolong, semua orang di utas ini, berikan aplikasi yang mereproduksi masalah ini. Saya belum bisa mereproduksinya. Tanpa langkah untuk mereproduksi, saya tergoda untuk menutup. Ada campuran rekomendasi dan mungkin masalah yang sangat berbeda terkubur dalam komentar ini. Sulit untuk mengetahui apa yang harus dilakukan dengan masalah ini.

@tilgovi Saya mengalami masalah ini ketika tidak menentukan kelas pekerja untuk gevent (misalnya menggunakan pekerja sinkronisasi default). Pengaturan saya adalah virtualenv menggunakan pypy3 (PyPy 5.8.0-beta0), falcon 1.2, dll (memahami Falcon tidak secara resmi didukung dengan pypy3). Saya menggunakan cookiecutter dari https://github.com/7ideas/cookiecutter-falcon dan memutakhirkan ke semua paket terbaru dan dalam mencoba memuat sample_resource di browser dan memukulnya berkali-kali dengan httpie sebentar-sebentar akan melihat kesalahan crash pekerja ( misalnya permintaan akan tertunda dan kemudian saya akan melihat kesalahannya; jika saya tidak membatalkan permintaan itu pada akhirnya akan merespons). Ini hanya terjadi dengan kelas sinkronisasi pekerja default. Ketika saya menentukannya untuk menggunakan gevent, semuanya berfungsi.

Terima kasih @jhillhouse92 , saya akan mencobanya.

Saya terus melihat masalah dengan batas waktu, @tilgovi. Saya akan memecahkan masalah ini lebih banyak besok dan akan memposting pembaruan dengan informasi yang lebih tepat. Harap tetap buka masalah ini; Anda benar bahwa mungkin ada berbagai masalah yang terjadi, tetapi tema umumnya adalah bahwa pekerja gunicorn (mungkin hanya dengan kelas pekerja sinkronisasi, tbd) mengalami masalah waktu habis saat menggunakan gunicorn dengan aplikasi yang digunakan menggunakan AWS/ELB. Ada sesuatu yang salah di sini, bahkan jika kita belum mengisolasi masalah yang sebenarnya. Layak untuk digali lebih jauh. Saya akan memperbarui besok.

Perlu dicatat, saya mengalami masalah ini secara lokal bukan di dalam Docker/AWS/ELB dengan tumpukan di atas yang saya sebutkan.

Jadi saya menggunakan gevent, mencoba menangkap log akses saya, dan mencoba menerapkan aplikasi saya menggunakan AWS/ELB.

perintah dockerfile:

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"]

Saya mendapatkan kesalahan OOM gila sehubungan dengan kode Kesalahan 14, terlepas dari apa yang saya tetapkan batasnya. Adakah orang lain yang melihat ini dalam konteks masalah ini? Sebelumnya, saya dapat melihat batas waktu pekerja. Dengan konfigurasi saya saat ini, saya tidak dapat mereproduksi batas waktu/sampai sejauh itu.

[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

Untuk mengulangi, saya tidak melihat ini secara lokal tanpa buruh pelabuhan. Saya tidak melihat ini secara lokal dengan Docker. Ini, dan masalah batas waktu, tampaknya hanya menjadi tumpukan Docker/AWS/ELB (untuk saya).

@tilgovi Satu hal yang awalnya saya lakukan salah (seperti yang dapat dilihat pada cuplikan yang saya posting di atas) adalah bahwa saya salah mengatur batas waktu menjadi 10 detik. Setelah mengubahnya menjadi 75 detik, jumlah waktu tunggu pekerja turun secara signifikan menjadi mungkin beberapa per hari. Untuk kelengkapan ini adalah perintah yang tepat yang saya gunakan untuk memulai aplikasi kami:

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

File .ini terlihat seperti 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

Jumlah lalu lintas tampaknya tidak menjadi faktor - saya melihat ini terjadi di lingkungan QA kami yang hanya melihat lalu lintas yang sangat sedikit.

Melihat seberapa sering ini terjadi, saya bertanya-tanya apakah ini terkait dengan restart aplikasi?

Saya memiliki masalah yang agak mirip. Setelah beberapa penyelidikan, saya pikir itu mungkin kesalahan koneksi jaringan, bukan gunicorn.

Inilah pengaturan saya:

• Server Postgresql berjalan di Docker di EC2. Gambar buruh pelabuhan adalah postgres resmi 9.6.
• Server aplikasi berjalan di Docker di VM di luar EC2. Gambar buruh pelabuhan adalah python 3.6 resmi.
• Hanya port 5432 / tcp yang dibuka di grup keamanan AWS.

Lucunya, sebagian besar permintaan dari server aplikasi ke server postgres baik-baik saja, kecuali satu. Kueri itu tampaknya berjalan selamanya, yang menghabiskan waktu pekerja gunicorn.

Masalahnya hilang jika saya menggunakan aplikasi secara lokal.

Masalahnya juga hilang jika saya tidak melakukan dockerize pada server aplikasi.

Perbaikan sementara saya membuka semua koneksi antara server aplikasi dan server postgres melalui pengaturan grup keamanan AWS. Sekarang semuanya berfungsi dengan baik lagi.

Dugaan saya ada masalah koneksi antara wadah Python dan AWS. Saya akan memperbarui setelah memeriksa aliran log AWS secara menyeluruh.

Terima kasih!! Mengubah ELB dan protokol Instance dari HTTP ke TCP berfungsi dengan baik 👍

Masalahnya tampaknya tidak spesifik untuk AWS, tetapi untuk Docker itu sendiri ketika dikombinasikan dengan Gunicorn. Saya melihat ini dengan gevent juga, setidaknya di lingkungan produksi kami.

@tilgovi Inilah aplikasi sederhana untuk membuat ulang kesalahan ini (

aplikasi.py:

import falcon


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


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

File Docker:

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

Untuk menjalankan: docker build -t gunicorn-and-docker . && docker run -p 8000:8000 -it --rm gunicorn-and-docker

Log akan terlihat seperti ini (setidaknya untuk saya di macOS Sierra menggunakan 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

Hai,

Saya baru-baru ini mengalami masalah yang sama.
Dalam kasus saya (ECS + gunicorn 19.7.1 + Django 1.11.5) saya (tampaknya) berhasil menyelesaikannya hanya dengan meningkatkan jumlah memori yang didedikasikan untuk wadah dalam definisi tugas (dari 128 menjadi 256mb).
Tidak ada lagi kesalahan sejauh ini. Saya akan melaporkan di sini jika itu terjadi lagi.

Menambahkan sedikit ke chorus di sini, tetapi saya dapat menyelesaikan ini hanya dengan beralih ke gevent.

Saya mencoba menambah batas waktu menjadi 90 dan tetap hidup menjadi 75 dengan pekerja sinkronisasi tanpa hasil.

Juga, yang menarik, ELB saya dalam skenario ini hanya melakukan penerusan level TCP dan bukan HTTP.

Oke, saya menemukan beberapa referensi yang menjelaskan hal ini. [1]

Itu bisa diselesaikan dengan perubahan kecil di sisi Gunicorn. Jika, di pekerja sinkronisasi, setelah menerima koneksi baru, kami memanggil select() dengan waktu tunggu yang singkat, maka kami dapat menangani koneksi ini. Ini bisa menjadi sedikit rumit, terutama dengan beberapa soket pendengaran. Hal paling sederhana adalah memiliki batas waktu ke byte pertama. Saya juga tidak yakin bagaimana itu akan berinteraksi dengan SSL.

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

Jika Anda mengalami ini dan tidak ingin menggunakan gevent/eventlet/asyncio, saya sarankan untuk beralih ke pekerja berulir (berikan pengaturan --threads ).

@tilgovi Masalahnya tampaknya juga ada pada pekerja gevent, jika Anda melihat contoh saya di atas.

@jmagnusson contoh Anda (dari komentar ini: https://github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187) tampaknya menggunakan pekerja sinkronisasi.

[23-09-2017 22:31:00 +0000] [1] [INFO] Menggunakan pekerja: sinkronisasi

@tilgovi Benar, tapi saya pernah mengalami ini dengan gevent pekerja juga, dalam produksi. Saya akan mencoba mencari waktu untuk mereproduksi dengan gevent.

Ini mungkin hanya saya (konyol), tetapi dalam grup keamanan EC2 -> aturan masuk, saya memiliki aturan TCP khusus untuk port 5000 (gunicorn di sini) untuk mengizinkan hanya satu IP (IP saya: XX.XX.XX.XX /32), mengubah ini ke semua IP akan membantu.

Saya bertemu dengan masalah, juga.

[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. 

Saya menambahkan log debug worker pid {WORKER_PID} notify .

Menurut log debug,

1. Hanya jika proses pekerja menerima satu permintaan, pemberitahuan tidak akan berjalan. Jadi, apakah ada permintaan atau tidak, master akan mematikan proses pekerja setelah 30-an.
2. Setelah permintaan pertama ditutup, saya mengirim permintaan kedua sekarang, tetapi permintaan kedua diblokir dan tidak ada tanggapan. Ketika batas waktu 30-an tercapai, proses pekerja dihentikan dan proses pekerja baru akan merespons permintaan kedua. Kemudian server telah digantung lagi.
3. Ketika proses pekerja telah digantung, itu tidak akan menerima sinyal dari master, seperti SIGTERM . Ketika batas waktu yang anggun tercapai, master akan membunuhnya dengan SIGKILL paksa.

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

PEMBERITAHUAN: Ketika saya menggunakan eventlet sebagai pekerja, tidak apa-apa.

Saya akan menutup masalah ini karena saya pikir ini sudah ketinggalan zaman. Seperti yang dapat saya tentukan, perilaku yang diamati adalah karena AWS Classic Load Balancer melakukan pengoptimalan pra-pembukaan. Pengoptimalan ini hanya dilakukan oleh Classic Load Balancer, sesuai dengan dokumentasi cara kerja load balancing . Beralih ke Application Load Balancers akan menyelesaikan masalah. Selain itu, seperti yang didokumentasikan dalam entri blog ini , Anda dapat meminta AWS untuk menonaktifkan pengoptimalan pra-pembukaan atau menambah waktu tunggu pekerja untuk Gunicorn.

@tilgovi FWIW saya melihat ini dengan ALB. Saya tidak pernah menggunakan penyeimbang beban klasik.

@tilgovi Saya juga mengamati ini berulang kali di lingkungan khusus ALB, tidak pernah menggunakan klasik. Bahkan dengan penyesuaian batas waktu pekerja, kami terus melihat ini.

@tilgovi saya bertemu dengan ini. Saya belum pernah menggunakan AWS.

Seseorang harus membantu mereproduksi ini, lalu, dan mencoba men-debugnya. Saya tidak dapat mereproduksinya dengan ALB dan saya tidak dapat melihat cara mereproduksinya di luar AWS.

@xgfone Anda mungkin ingin membuka masalah Anda sendiri, judul masalah ini adalah "docker + AWS"

Adakah yang mengalami ini dengan load balancer AWS tetapi tanpa Docker? Saya sedikit bingung, harus saya akui :)

Kesan saya adalah bahwa masalahnya benar-benar lebih terkait dengan Docker - setidaknya saya memiliki masalah yang persis sama saat menjalankan beberapa pekerja sinkronisasi gunicorn di dalam Docker di mesin lokal saya.

Konfigurasi ini berfungsi dengan baik tanpa Docker di mesin Ubuntu dan RHEL, baik bare metal maupun virtual di Digital Ocean:

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

Di dalam Docker (juga RHEL, semuanya sama), para pekerja selalu mengalami batas waktu dan terus memulai ulang secara permanen. Mengambil rekomendasi dari utas ini, saya telah beralih ke ini, yang berfungsi dengan baik:

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

Jika menurut Anda ini tidak terkait dengan utas ini, saya dengan senang hati menghapusnya dari sini dan meletakkannya di tempat lain ;-)

Terbaik, Boris

@tilgovi

Kesalahan ini terjadi di arbiter.py, murder_workers . Fungsi murder_workers dipanggil ketika SIG_QUEUE kosong (misalnya saat menunggu sinyal).

Kemudian akan memeriksa untuk melihat apakah batas waktu tercapai setiap detik. Waktu yang tersisa untuk hidup selalu 1 detik atau 0 detik karena pekerja gevent berada dalam loop tak terbatas terkontrol sementara self.alive dipanggil self.notify yang memperbarui file. Pembaruan file adalah bagaimana gunicorn memeriksa kapan waktu aktif terakhir terjadi.

Jadi, satu-satunya cara waktu untuk memeriksa langsung di fungsi murder_workers gagal (misalnya mengatakan itu sudah terlalu lama tidak digunakan) adalah jika properti gevent live diubah. Metode berikut mengontrol ini:

handle_quit
handle_request (jika permintaan maksimum diterima, secara default ini adalah 2^64 bit jumlah permintaan atau 2^32 jika OS 32-bit)
changed (dipanggil dari reloader jika file diubah)
handle_exit
handle_abort

Metode ini dipanggil dari sinyal

handle_quit - SIGQUIT, SIGINT
handle_exit - SIGTERM
handle_abort - SIGABRT

Jadi, ada 2 kemungkinan masalah yang saya lihat:

1. Metode notify tidak dapat memperbarui file selama loop-nya
2. Sinyal salah dikirim

Saya pikir penyebab yang lebih mungkin adalah yang ke-2. Sumber utama sinyal ada di dalam file arbiter dan dipicu oleh pengecualian ini:

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception (pengecualian tidak tertangani)

Saya pikir pengecualian StopIteration kemungkinan besar adalah pelakunya yang dipicu dalam file async.py di req = six.next(parser) . Tampaknya metode selanjutnya ini hanya menjalankan parser.next().

Parser.next() memunculkan pengecualian StopIteration pada 2 kondisi berikut:

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

Saya tidak yakin apa sebenarnya yang menyebabkan hal itu secara tidak sengaja tetapi dari 62 komentar dengan masalah ini terlihat di beberapa aplikasi dan lingkungan, saya pikir ini layak untuk diselidiki lebih lanjut dan merekomendasikan untuk membukanya kembali atau jika kami tidak menyukai judulnya , membuat masalah global baru dengan pekerja kritis waktu keluar.

Saya akan membuka kembali ini dan mencoba menguji kombinasi ini:

• Docker lokal
• Docker AWS dengan Classic Load Balancer
• Docker AWS dengan Application Load Balancer

Jika ada yang ingin membuat repo yang dapat mereproduksi ini, itu akan sangat membantu, tetapi saya mungkin bisa melakukannya akhir pekan ini.

Saya mengalami masalah ini dan saya tidak menggunakan AWS.
Pengaturan saya adalah NGINX -> wadah Docker (Gunicorn dengan pekerja gevent + Django). Saya menggunakan batas waktu default Gunicorn.

Ada tips?

Terima kasih.

Hai @davidmir ,
Saya memiliki masalah yang sama, mengubah tipe pekerja tidak membantu. Beralih ke satu pekerja sinkronisasi dengan banyak utas membantu saya:

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

Terbaik, Boris

Meskipun disebutkan beberapa di atas, untuk memperjelas dari debug saya sendiri tentang masalah ini, beberapa di antaranya adalah kesalahan memori; terutama jika diselesaikan dengan mengubah hitungan mundur pekerja menjadi 1.

Ini terutama bermasalah pada Docker jika Anda memiliki sesuatu seperti ini di konfigurasi Anda:

workers = multiprocessing.cpu_count() * 2 + 1

Tetapi membatasi memori yang tersedia untuk wadah; pekerja sinkron akan memulai beberapa penerjemah python yang berpotensi kelas berat. Perhatikan bahwa jumlah CPU didasarkan pada jumlah CPU keseluruhan mesin, bukan apa yang Anda sediakan untuk digunakan oleh wadah buruh pelabuhan; jika Anda menjalankan wadah terbatas, Anda harus mendasarkan jumlah pekerja pada itu.

Meskipun bervariasi dari aplikasi ke aplikasi, aturan praktis saya adalah 256 MB per pekerja dalam konfigurasi ramping dan 512 untuk amannya.

Menghadapi masalah yang sama menggunakan Classic ELB HTTPS => HTTP Gunicorn Sync Workers

Seperti yang disebutkan orang lain, perbaikan termudah adalah menggunakan argumen -k gevent alih-alih pekerja sinkronisasi default.

Kami melihat masalah yang sama muncul lagi untuk wadah Docker yang sama sekali baru (dihosting di ECS di belakang ALB), dan menemukan solusi yang sama sekali berbeda (tetapi di belakang, seharusnya sudah jelas): mengalokasikan lebih banyak memori ke wadah di CloudFormation templat.

Kami mengalami masalah ini tahun lalu dan tidak pernah menemukan akar masalah merokok, tetapi malam ini saya melihatnya di wadah baru, dan kebetulan memperhatikan bahwa wadah itu menghabiskan semua memori yang telah kami alokasikan. Segera setelah saya menggandakan alokasi, wadah berhenti melempar kesalahan ini (bahkan sebelum saya mengalokasikan lebih dari yang pada akhirnya akan dikonsumsi):
https://github.com/hackoregon/civic-devops/issues/157

Menghadapi masalah serupa di sini. kodenya sesederhana

while true:
      sleep(10)

dapat menyebabkan pekerja sekarat (tanpa kode ini, penyebaran kami normal)
itu sangat membingungkan, b/c sleep seharusnya sudah mengirim detak jantung.

juga sudah berubah menjadi gevent, tidak membantu. Bertanya-tanya apakah ada yang punya pemikiran?

keluaran sampel:
[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

Maaf untuk memperkeruh air di sini tetapi hanya ingin berbagi pengalaman saya, tumpukan saya adalah HTTP ELB > Nginx > gunicorn/gevent on EC2 , proses berjalan menggunakan sirkus

Masalah yang saya temukan adalah bahwa setelah melengkapi aplikasi Django saya dengan elastic- apm pemeriksaan kesehatan HTTP saya akan segera mulai gagal dan gunicorn akan menjadi tidak responsif setelah beberapa detik.

Saya mencoba beberapa tolok ukur wrk terhadap pemeriksaan kesehatan saya, sinkronisasi mendapatkan sekitar 300rps untuk 1-5 pekerja, tetapi gevent akan mendapatkan 1rps. Mematikan apm membawa gevent hingga sekitar 50 rps dan peningkatan yang dapat diabaikan untuk sinkronisasi.

Tidak melihat penggunaan memori yang aneh pada valgrind, biasanya sekitar 4MB untuk gunicorn dan 40MB per pekerja

Bagaimanapun, memperbarui gunicorn 19.6.0 > 19.9.0 dan gevent 1.2.2 > 1.3.6 memberi saya pemeriksaan kesehatan ELB yang kokoh lagi dan ~300rps secara lokal. Saya sengaja tidak memperbarui gunicorn/gevent sampai saya memiliki beberapa APM yang masuk, tampaknya melakukan itu telah mendorong beberapa kebetulan. Memperbarui gevent memberikan dorongan terbesar, dapat dimengerti, tetapi kemudian memperbarui gunicorn tampaknya menambah 10% atau lebih.

Belum melihat log perubahan secara lebih rinci, mungkin pengelola dapat menjelaskan penyebab yang paling mungkin?

Bagaimanapun, memperbarui gunicorn 19.6.0 > 19.9.0 dan gevent 1.2.2 > 1.3.6 memberi saya pemeriksaan kesehatan ELB yang kokoh lagi dan ~ 300rps secara lokal....Memperbarui gevent memberikan dorongan terbesar

Wow, itu cukup keren!

masalah penutup. tidak ada aktivitas sejak beberapa saat.

FWIW, saya masih mengalami masalah ini @benoitc :-\

Django 2.1.5
gunicorn 19.8.1
peristiwa 1.2.2
AKS 1.15.7 dengan 5 Node (standar B2 - 2 vcore dan memori 2GB)
3 pod/kontainer buruh pelabuhan, yang masing-masing memiliki:

    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"

Masalah yang sama di sini dengan EKS, Nginx, dan NLB.

@salmicrosoft @sinkr OK tapi tolong buka masalah baru dan berikan log apa pun yang Anda miliki yang dapat membantu kami mengetahui apa yang terjadi. Juga apa aplikasi Anda? Apakah Anda memiliki permintaan panjang?

Saya memiliki masalah yang sama pada ECS Fargate, tetapi itu terkait dengan pengaturan keepalive/timeout yang salah di Docker/gunicorn.conf.py, itu
keepalive (tidak diatur)
batas waktu = 2

Sebelum memperbaikinya berfungsi dengan baik dengan wadah yang berjalan secara lokal, tetapi gagal di ECS Fargate, sekarang berfungsi dengan benar di kedua lingkungan.