Gunicorn: "Pekerja booting" berulang tanpa batas meskipun tidak ada sinyal keluar

ssh masuk ke wadah Docker membuat saya menemukan kesalahan ini:

Illegal instruction (core dumped)

Mungkin gunicorn harus memunculkan kesalahan seperti ini alih-alih menelannya, atau menanganinya secara berbeda? Tidak yakin, hanya berpikir saya akan mengangkat ini karena mungkin membantu orang lain!

Terima kasih telah melaporkan masalah ini!

Jika Anda dapat mengetahui di mana ini terjadi, itu akan sangat membantu.

Mungkin kita bisa menambahkan logging saat pekerja keluar. Biasanya, pekerja itu sendiri mencatat, tetapi jika dibunuh dengan sangat tiba-tiba, itu tidak akan terjadi.

Jangan khawatir!

Tampaknya ada masalah dengan Spacy yang baru saja saya tambahkan ke utas ini: https://github.com/explosion/spaCy/issues/1589

Bagaimanapun, itu menyebabkan SIGILL sebagai strace mengkonfirmasi:

--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7ff48bbe6cea} ---
+++ killed by SIGILL (core dumped) +++
Illegal instruction (core dumped)

Saya kira akan lebih baik jika gunicorn dapat mengidentifikasi ini dan mencatat kesalahan daripada memulai ulang pekerja secara hantu, tetapi saya hanya tahu sedikit tentang cara kerja kode keluar!

Beberapa kode keluar pasti memiliki arti khusus dan kita mungkin bisa mencatatnya.
http://tldp.org/LDP/abs/html/exitcodes.html

Kedengarannya bagus! Selain itu jika kode keluar bukan kode keluar yang dicadangkan (seperti kasus ini), akan lebih keren jika itu bisa dicatat (tanpa penjelasan) sehingga jelas bahwa pekerja tersebut memang sedang mengakhiri

Saya memiliki masalah serupa, gunicorn selalu mem-boot pekerja baru ketika saya membuat permintaan http. Saya tidak mendapatkan respons apa pun, itu hanya selalu me-reboot pekerja baru. Strace log dari dua permintaan http:

select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=510, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=32} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 510
lseek(8, 0, SEEK_CUR)                   = 0
close(8)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 840340})     = 1 (in [3], left {0, 840338})
read(3, ".", 1)                         = 1
read(3, 0x7f2682025fa0, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-q4aa72u7", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 8
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-q4aa72u7", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-q4aa72u7")       = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(8, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(8, 0, SEEK_CUR)                   = 0
lseek(8, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 558
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 37381}[2017-12-28 17:50:23 +0000] [558] [INFO] Booting worker with pid: 558
) = 0 (Timeout)
select(4, [3], [], [], {1, 0}loading test-eu-ovh settings
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0}
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=499, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=31} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 499
lseek(7, 0, SEEK_CUR)                   = 0
close(7)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 450691})     = 1 (in [3], left {0, 450689})
read(3, ".", 1)                         = 1
read(3, 0x7f2682067de8, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-5x9a40ca", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 7
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-5x9a40ca", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-5x9a40ca")       = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(7, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(7, 0, SEEK_CUR)                   = 0
lseek(7, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 579
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 8144}[2017-12-28 17:50:30 +0000] [579] [INFO] Booting worker with pid: 579
)  = 0 (Timeout)
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0

Saya menghadapi masalah yang sama, gunicorn booting berulang dalam hitungan detik untuk tipe pekerja sync . Menyetel batas waktu pekerja ke 900 tidak membantu.

Dalam pemuatan saya sebelum tindakan, saya mengunduh data dari AWS S3. Dibutuhkan sekitar 1 menit 10 detik untuk mengunduh berbagai file.

@sara-02 apa baris perintah Anda untuk meluncurkan gunicorn?

@benoitc gunicorn --pythonpath /src -b 0.0.0.0:$SERVICE_PORT --workers=1 -k sync -t $SERVICE_TIMEOUT flask_endpoint:app
Hadir disini

@sara-02 Terima kasih.

Apakah pekerja lama benar-benar keluar atau mereka tetap online dan pekerja baru muncul? Apa yang ditunjukkan oleh log debug juga?

Log dicampur dengan log botocore, tetapi kira-kira seperti ini

[INFO] Booting worker with pid:  a
[INFO] Booting worker with pid:  b
[INFO] Booting worker with pid:  c

tetapi apakah pekerja itu terbunuh? apa yang mengembalikan perintah ps ax|grep gunicorn ?

@benoitc

Satu pertanyaan, mengapa kita melihat 2 proses gunicorn , ketika batas pekerja disetel ke 1? Apakah satu master, dan satu pekerja?

Ada 1 proses arbiter (master) dan N pekerja proses ya :)

Jadi Anda menjalankan perintah setiap kali seorang pekerja boot kan? Jika demikian, tampaknya pekerja yang lebih tua terbunuh, yang baru muncul. Saya akan menyelidiki.

@sara-02 satu hal terakhir, ini juga terjadi di buruh pelabuhan?

@benoitc pada docker-compose berfungsi seperti yang diharapkan, tetapi ketika saya meletakkan kode yang sama pada Openshift , saya melihat kesalahan ini. Meningkatkan kebutuhan memori memang memperbaiki, tetapi ketika saya menjalankan aplikasi melalui docker-compose itu menggunakan kurang dari limited memori.

Hanya pembaruan, masalah bagi saya sebenarnya adalah kesalahan memori dan diperbaiki ketika masalah memori diperbaiki.

@benoitc
Saya menghadapi Masalah yang sama ketika mencoba menelurkan 5 pekerja gunicorn di buruh pelabuhan.
@sara-02
Bagaimana Anda mengidentifikasi penyebab kesalahan memori?

@gulshan-gaurav 2 hal membantu saya:
Saya meningkatkan memori yang ditetapkan untuk Pod saya dan berhenti mogok. Kedua, kami memeriksa log Openshift Zabbix kami.

@sara-02
Bahkan pada Pod pementasan saya, file + model yang saya muat dalam memori berjumlah 50Mb sehingga memori 2GB harus cukup untuk 5 pekerja.

@gulshan-gaurav masalah apa yang Anda hadapi? Memiliki 5 proses di sana terlihat bagus ....

Saya memiliki masalah yang sama. Saya tidak menemukan masalah yang tepat, tetapi diselesaikan setelah saya memutakhirkan dari python 3.5 ke 3.6.

Saya menghadapi masalah yang sama dalam wadah Docker. Gunicorn terus membotolkan pekerja baru setiap kali saya memanggil titik akhir yang menyebabkan kegagalan tetapi tidak pengecualian atau kesalahan dikeluarkan ke dalam file log Gunicorn. Hal-hal yang saya pilih untuk dicetak dicatat dan kemudian tiba-tiba file log hanya mengatakan "Pekerja boot dengan pid ..."

Satu langkah yang membantu adalah menambahkan variabel env PYTHONUNBUFFERED. Sebelum itu, bahkan pernyataan cetak akan hilang dan tidak akan disimpan di log Gunicorn.

2 titik akhir lain dari aplikasi berfungsi dengan benar.

Saya menjalankan Gunicorn dengan: gunicorn run:app -b localhost:5000 --enable-stdio-inheritance --error-logfile /var/log/gunicorn/error.log --access-logfile /var/log/gunicorn/access.log log --capture-output --log-level debug

Sudah menjalankan Python 3.6 dan memeriksa dengan atas bahwa memori sepertinya tidak menjadi masalah.

EDIT: Sepertinya itu masalah Python dan bukan kesalahan Gunicorn. Beberapa perbedaan versi menyebabkan Python mati begitu saja tanpa jejak saat melakukan operasi tertentu.

Saya menghadapi masalah serupa di mana simpul pekerja terus muncul
Booting worker with pid: 17636 . saya tidak tahu apakah itu membunuh simpul pekerja sebelumnya atau simpul pekerja sebelumnya masih ada. Tetapi jumlah pekerja yang disebutkan dalam argumen baris perintah gunicorn hanya 3 - -workers=3 . Saya juga menggunakan python versi 3.7

Saya memiliki ketidakcocokan ketergantungan scikit-learn, tetapi bahkan setelah menyelesaikannya, saya masih mendapatkan pekerja tak terbatas yang sama. perbedaan versi python apa yang harus saya cari dan bagaimana cara mengidentifikasinya?

Saya menghadapi masalah yang sama di dalam OpenShift.

Seperti yang Anda lihat pada gambar, saya menggunakan 6 pekerja (saya mencoba dengan 3).
Saya meningkatkan memori pod dan tidak berhasil.

BuildConfig:

Ada ide?

Terima kasih

apakah Anda menjalankan ini di aws di belakang elb? Saya memecahkan masalah itu dengan menempatkan nginx ingress antara elb dan gunicorn

Punya masalah yang sama.

flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Starting gunicorn 19.9.0
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Using worker: sync
flask_1  | [2019-02-23 09:08:17 +0000] [8] [INFO] Booting worker with pid: 8
flask_1  | [2019-02-23 09:08:19 +0000] [12] [INFO] Booting worker with pid: 12
flask_1  | [2019-02-23 09:08:19 +0000] [16] [INFO] Booting worker with pid: 16
flask_1  | [2019-02-23 09:08:20 +0000] [20] [INFO] Booting worker with pid: 20
flask_1  | [2019-02-23 09:08:21 +0000] [24] [INFO] Booting worker with pid: 24
flask_1  | [2019-02-23 09:08:22 +0000] [28] [INFO] Booting worker with pid: 28
flask_1  | [2019-02-23 09:08:23 +0000] [32] [INFO] Booting worker with pid: 32
flask_1  | [2019-02-23 09:08:25 +0000] [36] [INFO] Booting worker with pid: 36
flask_1  | [2019-02-23 09:08:26 +0000] [40] [INFO] Booting worker with pid: 40
flask_1  | [2019-02-23 09:08:27 +0000] [44] [INFO] Booting worker with pid: 44
flask_1  | [2019-02-23 09:08:29 +0000] [48] [INFO] Booting worker with pid: 48
flask_1  | [2019-02-23 09:08:30 +0000] [52] [INFO] Booting worker with pid: 52
flask_1  | [2019-02-23 09:08:31 +0000] [56] [INFO] Booting worker with pid: 56
flask_1  | [2019-02-23 09:08:33 +0000] [60] [INFO] Booting worker with pid: 60
flask_1  | [2019-02-23 09:08:34 +0000] [64] [INFO] Booting worker with pid: 64
flask_1  | [2019-02-23 09:08:35 +0000] [68] [INFO] Booting worker with pid: 68
flask_1  | [2019-02-23 09:08:36 +0000] [72] [INFO] Booting worker with pid: 72
flask_1  | [2019-02-23 09:08:37 +0000] [76] [INFO] Booting worker with pid: 76
flask_1  | [2019-02-23 09:08:38 +0000] [80] [INFO] Booting worker with pid: 80
flask_1  | [2019-02-23 09:08:40 +0000] [84] [INFO] Booting worker with pid: 84
flask_1  | [2019-02-23 09:08:41 +0000] [88] [INFO] Booting worker with pid: 88
flask_1  | [2019-02-23 09:08:42 +0000] [92] [INFO] Booting worker with pid: 92
flask_1  | [2019-02-23 09:08:44 +0000] [96] [INFO] Booting worker with pid: 96
flask_1  | [2019-02-23 09:08:45 +0000] [100] [INFO] Booting worker with pid: 100
flask_1  | [2019-02-23 09:08:45 +0000] [104] [INFO] Booting worker with pid: 104
flask_1  | [2019-02-23 09:08:46 +0000] [108] [INFO] Booting worker with pid: 108
flask_1  | [2019-02-23 09:08:47 +0000] [112] [INFO] Booting worker with pid: 112
flask_1  | [2019-02-23 09:08:48 +0000] [116] [INFO] Booting worker with pid: 116
flask_1  | [2019-02-23 09:08:49 +0000] [120] [INFO] Booting worker with pid: 120
flask_1  | [2019-02-23 09:08:50 +0000] [124] [INFO] Booting worker with pid: 124
flask_1  | [2019-02-23 09:08:52 +0000] [128] [INFO] Booting worker with pid: 128

Ini docker-compose.yml :

version: '3'
services:
  flask:
    build: .
    command: gunicorn -b 0.0.0.0:5000 hello:app --reload
    environment:
      - FLASK_APP=hello.py
      - FLASK_DEBUG=1
      - PYTHONUNBUFFERED=True
    ports:
      - "5000:5000"
    volumes:
      - ./:/root

gambar buruh pelabuhan apa yang digunakannya?

@benoitc

[ec2-user@ip-172-31-85-181 web-services-course]$ docker --version
Docker version 18.06.1-ce, build e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
[ec2-user@ip-172-31-85-181 web-services-course]$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

Berikut ini tautan untuk:

• Dockerfile https://github.com/glebmikha/web-services-course/blob/master/Dockerfile
• docker-compose.yml https://github.com/glebmikha/web-services-course/blob/master/docker-compose.yml

tahu itu mungkin disebabkan oleh kurangnya memori. aplikasi membutuhkan lebih banyak memori daripada yang tersedia.
tapi itu hanya asumsi

Sekedar informasi: Saya telah mengamati persis perilaku ini ketika saya memiliki gunicorn conf untuk 3 pekerja, tetapi saya menggunakan kode di mesin virtual dengan CPU inti tunggal. Kemudian, saya mengubah lingkungan untuk menggunakan 2 inti, dan jelas masalahnya hilang

Mengapa 'Pekerja keluar' hanya pada level INFO -- mengapa seorang pekerja keluar kecuali karena kesalahan? Butuh waktu lama bagi saya untuk mengetahui bahwa utas pekerja saya dibunuh oleh pembunuh sistem OOM, tanpa apa pun di log kecuali, seperti yang dilaporkan oleh beberapa orang lain di atas, 'Pekerja boot dengan pid' dari waktu ke waktu.

@HughWarrington karena pekerja yang keluar belum tentu merupakan kesalahan. Pekerja dapat dihentikan dengan sinyal atau opsi seperti --max-requests .

@HughWarrington kita mungkin bisa menambahkan logging di arbiter ketika seorang pekerja keluar dengan kode keluar yang tidak normal.

Anda dapat membuka tiket untuk itu, atau menyumbangkan PR yang menambahkan kode ini ke metode reap_workers .

Saya memiliki masalah yang sama, dan solusinya adalah menambah ukuran memori pod.

Memiliki masalah yang sama saat menjalankan Gunicorn di Docker dengan model spaCy besar, ia terus memulai ulang pekerja tanpa pesan kesalahan. Solusinya adalah menambah memori untuk wadah Docker.

Baru saja mengalami masalah ini hari ini pada gunicorn (19.9.0) terbaru dengan pekerja gevent (1.4.0) yang berjalan di Kubernetes. Aplikasi ini adalah aplikasi Falcon dan gambar Docker adalah gambar Python resmi dengan tag 3.7.3 .

[2019-07-05 00:07:42 +0000] [8] [INFO] Starting gunicorn 19.9.0
[2019-07-05 00:07:42 +0000] [8] [INFO] Listening at: http://0.0.0.0:5000 (8)
[2019-07-05 00:07:42 +0000] [8] [INFO] Using worker: gevent
[2019-07-05 00:07:43 +0000] [35] [INFO] Booting worker with pid: 35
[2019-07-05 00:07:43 +0000] [36] [INFO] Booting worker with pid: 36
[2019-07-05 00:07:43 +0000] [37] [INFO] Booting worker with pid: 37
[2019-07-05 00:07:43 +0000] [38] [INFO] Booting worker with pid: 38
[2019-07-05 00:07:43 +0000] [41] [INFO] Booting worker with pid: 41
[2019-07-05 00:07:43 +0000] [43] [INFO] Booting worker with pid: 43
[2019-07-05 00:07:43 +0000] [45] [INFO] Booting worker with pid: 45
[2019-07-05 00:07:43 +0000] [49] [INFO] Booting worker with pid: 49
[2019-07-05 00:07:43 +0000] [47] [INFO] Booting worker with pid: 47
[2019-07-05 00:07:49 +0000] [53] [INFO] Booting worker with pid: 53
[2019-07-05 00:07:50 +0000] [54] [INFO] Booting worker with pid: 54
[2019-07-05 00:07:53 +0000] [57] [INFO] Booting worker with pid: 57
[...]

Pod memiliki pengaturan sumber daya berikut:

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Menggandakan semuanya memperbaiki masalah.

Satu hal menarik yang kami perhatikan adalah ketika melihat dmesg pada mesin host, kami dapat melihat bahwa itu adalah segfault pada libcrypto saat mengakses server menggunakan SSL

Memori sepertinya tidak menjadi masalah bagi saya karena saya tidak memuat model besar apa pun di memori. Pekerja terus mogok dan saya tidak dapat melihat pesan kesalahan apa pun. Apakah ada perbaikan untuk ini?

masalah yang sama untuk saya, ada ide untuk memperbaikinya? python 3.6.3 dengan gunicorn 19.9.0

@MrKiven apa aplikasi Anda? apakah Anda menggunakan hal-hal seperti permintaan?

dapatkah seseorang memberikan cara untuk mereproduksi masalah?

Ini adalah manajer dari beberapa komponen yang dieksekusi dalam pipa. Beberapa dari mereka mungkin memulai permintaan HTTP ke komponen lain pada mesin yang sama atau pada mesin jarak jauh. Beberapa modul dari pipeline dapat dieksekusi secara paralel tetapi dieksekusi menggunakan ThreadPoolExecutor. Mereka tidak menggunakan objek bersama tetapi mereka hanya menghasilkan struktur data yang kemudian digabungkan dalam satu hasil tunggal.

Sayangnya saya tidak yakin apakah saya dapat mengumpulkan contoh minimal tanpa memaparkan sistem yang kami miliki.

permintaan melakukan banyak hal yang tidak aman dengan utas yang terkadang memotong proses baru. Saya akan menyarankan untuk menggunakan klien lain. dapatkah Anda menempelkan setidaknya baris yang Anda gunakan untuk melakukan permintaan? Apakah Anda menggunakan fitur batas waktu?

Salah satunya bisa berupa:

try:
     resp = requests.post(self._endpoint, json=request_data)

     if resp.status_code != 200:
          logger.critical("[Error]: status code is {}".format(resp.status_code))
          return None

     response = resp.json()
     return {"intent": response["intent"], "intent_ranking": response["intent_ranking"]}
except ConnectionError as exc:
     logger.critical("[Exception] {}".format(str(exc)))
     return None

Terima kasih. Saya akan mencoba membuat yang sederhana darinya.

Akan lebih keren lagi jika seseorang dapat mengirimi kami pr yang mereproduksi perilaku baik sebagai contoh atau pengujian unit sehingga kami memastikan bahwa kami benar-benar memperbaiki hal yang benar.

Tidak yakin apakah itu dapat membantu seseorang tetapi saya memiliki masalah yang sama saat menjalankan aplikasi web labu dockerized dan menyelesaikannya dengan memperbarui gambar dasar dockerfile saya menjadi python:3.6.9-alpine

Dmesg pada host menunjukkan segfault pada lilibpython3.6m.so.1.0:

[626278.653010] gunicorn[19965]: segfault at 70 ip 00007f6423e7faee sp 00007ffc4e9a2a38 error 4 in libpython3.6m.so.1.0[7f6423d8a000+194000]

Gambar buruh pelabuhan saya didasarkan pada python:3.6-alpine dan melakukan apk update yang memperbarui python ke 3.6.8.

Seperti yang dikatakan mengubah gambar dasar menjadi python:3.6.9-alpine menyelesaikannya untuk saya

Saya menghadapi tantangan yang sama menjalankan Flask + Docker + Kubernetes. Meningkatkan batas CPU dan Memori menyelesaikannya untuk saya.

Hal yang sama terjadi pada kami. Meningkatkan batas sumber daya memperbaiki masalah.

Ini tiba-tiba terjadi pada saya di macOS Catalina (tidak dalam wadah).

Yang membantu saya adalah:

1. Menginstal openssl:

brew install openssl

1. Menjalankan dan menambahkan ini ke ~/.zshrc :

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib:$DYLD_LIBRARY_PATH

Sumber: https://stackoverflow.com/a/58445755/5811984

Saya mengalami tantangan serupa dan akan berterima kasih jika seseorang dapat membantu saya.
Inilah yang saya miliki;

" root@ubuntu-s-1vcpu-1gb-nyc1-01 :~# sudo systemctl status gunicorn.service ● gunicorn.service - daemon gunicorn Dimuat: dimuat (/etc/systemd/system/gunicorn.service; dinonaktifkan; preset vendor: diaktifkan) Aktif: aktif (berjalan) sejak Senin 24-02-2020 07:48:04 UTC; 44 menit yang lalu PID Utama: 4846 (gunicorn) Tugas: 4 (batas: 1151) CGroup: /system.slice/gunicorn.service 4846 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - 4866 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoproject /bin/gunicorn - 4868 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - 4869 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home /bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - 24 Feb 07:48:04 ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: Menghentikan daemon gunicorn 24 Feb 07:48:04 ubuntu-s-1vcpu -1gb-nyc1-01 systemd[1 ]: Memulai daemon gunicorn. 24 Feb 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] Memulai gunicorn 20.0.4 24 Feb 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] Mendengarkan di: unix:/run/gunicorn .soc 24 Feb 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] Menggunakan pekerja: sinkronisasi Feb 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4866] [INFO] Boot pekerja dengan pid: 4866 24 Feb 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4868] [INFO] Boot pekerja dengan pid: 4868 Feb 24 07 :48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4869] [INFO] Boot pekerja dengan pid: 4869 24 Feb 08: 03:41 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: - - [24/Feb/2020:08:03:41 +0000] "GET / HTTP/1.0" 400 26 "-" "Mozilla /5.0 (Jalur Wi 1-20/20 (AKHIR)" Adakah yang bisa membantu saya memperbaikinya?

@BrightNana dapatkah Anda mencoba memberikan dmesg dan melihat apakah Anda memiliki kesalahan gunicorn?
dmesg | grep gunicorn dapat membantu menyaring kesalahan lainnya

Halo,
saya memiliki bug yang sama di debian 9 ketika saya ingin menyediakan gunicorn sebagai layanan systemd. Jika saya memulainya dari CLI, gunicorn berjalan tanpa kesalahan.

Ekstrak dari dmesg | grep gunicorn :

Kutipan dari journalctl :
Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1054] [INFO] Booting worker with pid: 1054 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1057] [INFO] Booting worker with pid: 1057 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1060] [INFO] Booting worker with pid: 1060 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1064] [INFO] Booting worker with pid: 1064 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1067] [INFO] Booting worker with pid: 1067 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1070] [INFO] Booting worker with pid: 1070 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1073] [INFO] Booting worker with pid: 1073 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1076] [INFO] Booting worker with pid: 1076 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1079] [INFO] Booting worker with pid: 1079 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1082] [INFO] Booting worker with pid: 1082 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1085] [INFO] Booting worker with pid: 1085 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1088] [INFO] Booting worker with pid: 1088 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1091] [INFO] Booting worker with pid: 1091 Mär 12 07:01:09 build-server gunicorn[828]: [2020-03-12 07:01:09 +0100] [1094] [INFO] Booting worker with pid: 1094
Ekstrak dari systemctl status :
● api.service - API Server for BuildingChallenge served with Gunicorn Loaded: loaded (/etc/systemd/system/api.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 08:26:01 CET; 22min ago Main PID: 8150 (gunicorn) Tasks: 3 (limit: 4915) Memory: 37.7M (high: 100.0M max: 500.0M) CGroup: /system.slice/api.service ├─ 8150 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app ├─28936 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app └─28938 /usr/bin/python3 -Es /usr/bin/lsb_release -a Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28909] [INFO] Booting worker with pid: 28909 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28912] [INFO] Booting worker with pid: 28912 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28915] [INFO] Booting worker with pid: 28915 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28918] [INFO] Booting worker with pid: 28918 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28921] [INFO] Booting worker with pid: 28921 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28924] [INFO] Booting worker with pid: 28924 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28927] [INFO] Booting worker with pid: 28927 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28930] [INFO] Booting worker with pid: 28930 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28933] [INFO] Booting worker with pid: 28933 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28936] [INFO] Booting worker with pid: 28936

Terima kasih atas bantuan Anda.

Saya memasang PR yang mungkin membantu men-debug situasi semacam ini. Ada yang bisa lihat?
https://github.com/benoitc/gunicorn/pull/2315

Saya memiliki masalah yang sama dengan aplikasi Flask yang berjalan di dalam Docker. Para pekerja memulai ulang tanpa batas dengan ID proses yang meningkat.

Masalahnya terkait memori bagi saya, ketika saya meningkatkan memori yang diizinkan untuk Docker, para pekerja muncul secara efektif.

@tilgovi , saya tidak keberatan jika Anda ingin memasukkan perubahan saya ke dalam PR Anda sejak Anda tiba di sana terlebih dahulu. Ini akan mencakup pekerja yang terbunuh melalui sinyal.

@mildebrandt saya akan lihat, terima kasih!

Saya juga melihat perilaku ini tiba-tiba, menggunakan Gunicorn (20.0.4) + Gevent (1.5.0) + Flask di dalam wadah Docker.

[  328.699160] gunicorn[5151]: segfault at 78 ip 00007fc1113c16be sp 00007ffce50452a0 error 4 in _greenlet.cpython-37m-x86_64-linux-gnu.so[7fc11138d000+3e000]

Dalam kasus saya, seperti yang Anda lihat, segfault disebabkan oleh gevent. Yang aneh adalah wadah ini berfungsi dengan baik 5 hari yang lalu, dan tidak ada kode yang berubah sejak itu mengubah versi perpustakaan mana pun, dan semuanya disetel ke rilis tertentu. Saya memang menghapus flask-mail sebagai dependensi, yang mungkin sedikit mengubah versi dependensi lainnya.

Memperbarui dari gevent==1.5.0 ke gevent==20.9.0 menyelesaikan masalah bagi saya.

@ifiddes masalah Anda kemungkinan tidak terkait. Anda melihat masalah kompatibilitas ABI antara versi lama gevent dengan versi terbaru greenlet. Lihat https://github.com/python-greenlet/greenlet/issues/178

Ah, terima kasih @jamadden. Hanya posting ini yang dapat saya temukan ketika mencari pemijahan tak terbatas dari pekerja booting, tetapi masalah itu dan waktu masalah itu sesuai dengan masalah saya.

Saya memiliki kesalahan serupa dengan mesin AWS baru dengan Ubuntu 20.04 Server dan dengan kode yang sama yang berfungsi pada produksi.

Mesin dikonfigurasi menggunakan Ansible seperti mesin produksi lainnya.

[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Current configuration:
  config: None
  bind: ['127.0.0.1:8000']
  backlog: 2048
  workers: 1
  worker_class: uvicorn.workers.UvicornWorker
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /var/www/realistico/app
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1001
  group: 1001
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: /var/www/realistico/logs/gunicorn/access.log
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: /var/www/realistico/logs/gunicorn/error.log
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  dogstatsd_tags: 
  statsd_prefix: 
  proc_name: None
  default_proc_name: realistico.asgi:application
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f7ba5fdd550>
  on_reload: <function OnReload.on_reload at 0x7f7ba5fdd670>
  when_ready: <function WhenReady.when_ready at 0x7f7ba5fdd790>
  pre_fork: <function Prefork.pre_fork at 0x7f7ba5fdd8b0>
  post_fork: <function Postfork.post_fork at 0x7f7ba5fdd9d0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f7ba5fddaf0>
  worker_int: <function WorkerInt.worker_int at 0x7f7ba5fddc10>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f7ba5fddd30>
  pre_exec: <function PreExec.pre_exec at 0x7f7ba5fdde50>
  pre_request: <function PreRequest.pre_request at 0x7f7ba5fddf70>
  post_request: <function PostRequest.post_request at 0x7f7ba5f6e040>
  child_exit: <function ChildExit.child_exit at 0x7f7ba5f6e160>
  worker_exit: <function WorkerExit.worker_exit at 0x7f7ba5f6e280>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f7ba5f6e3a0>
  on_exit: <function OnExit.on_exit at 0x7f7ba5f6e4c0>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: None
  raw_paste_global_conf: []
  strip_header_spaces: False
[2020-10-15 15:11:49 +0000] [18068] [INFO] Starting gunicorn 20.0.4
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Arbiter booted
[2020-10-15 15:11:49 +0000] [18068] [INFO] Listening at: unix:/run/gunicorn.sock (18068)
[2020-10-15 15:11:49 +0000] [18068] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-10-15 15:11:49 +0000] [18080] [INFO] Booting worker with pid: 18080
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] 1 workers
[2020-10-15 15:11:51 +0000] [18083] [INFO] Booting worker with pid: 18083
[2020-10-15 15:11:53 +0000] [18086] [INFO] Booting worker with pid: 18086
...
[2020-10-15 15:12:09 +0000] [18120] [INFO] Booting worker with pid: 18120
[2020-10-15 15:12:11 +0000] [18123] [INFO] Booting worker with pid: 18123

Setelah berkali-kali mencoba menyelesaikan masalah ini tanpa hasil (dan tanpa kesalahan pada log), saya telah mencoba dengan Hello world ini dan saya menemukan kesalahan ini:

ModuleNotFoundError: No module named 'httptools'

Setelah menginstal httptools aplikasi Hello world berfungsi dengan baik dan, secara tidak terduga, juga berfungsi dengan aplikasi saya.

Saya tidak tahu mengapa kesalahan tidak dicatat atau mengapa perpustakaan ini diinstal pada mesin lain tetapi tidak pada yang baru, tetapi ini memperbaiki masalah bagi saya.

Seandainya ini terjadi baru-baru ini dan hapus simpul kubernetes yang aktif dengan menggunakan semua CPU. Berkat petunjuk tentang dmesg saya menemukan kesalahan:

[225027.348869] traps: python[44796] general protection ip:7f8bd8f8f8b0 sp:7ffc21a0b370 error:0 in libpython3.7m.so.1.0[7f8bd8dca000+2d9000]

Pada akhirnya masalah saya adalah contoh lain dari https://github.com/python-greenlet/greenlet/issues/178 dan diselesaikan dengan memperbarui gunicorn, gevent, dan greenlet ke versi terbaru.

Karena jenis pengecualian ini tidak membuat log python, tidak dapat ditangkap, mengembalikan kode keluar 0, dan dapat menggantung mesin saat terjadi, mereka cukup sulit untuk dikelola.

Saya mengusulkan agar gunicorn mendeteksi crash-looping cepat seperti ini dan

• menyerah atau membatasi tingkat pemijahan pekerja baru
• berikan pesan berguna yang mengarahkan orang ke masalah ini dan https://github.com/python-greenlet/greenlet/issues/178

mungkin max_consecutive_startup_crashes dengan default num_workers * 10 ?

Mari lacak permintaan fitur loop macet di #2504. Kami juga memiliki PR untuk login tambahan di #2315. Saya akan menutup masalah ini karena sepertinya semua orang telah men-debug masalah mereka dan sekarang kami memiliki beberapa permintaan fitur dan peningkatan untuk membantu orang lain di masa mendatang. Terimakasih semuanya!