Apakah itu nginx smooth restart dan FPM smooth restart?

Graceful Restart

GR ialah singkatan dari Graceful Restart Ia merupakan satu mekanisme untuk memastikan perkhidmatan penghantaran semula tidak terganggu apabila protokol dimulakan semula.
Inti mekanisme GR ialah apabila peranti memulakan semula protokol, ia boleh memberitahu peranti sekelilingnya untuk mengekalkan hubungan jiran yang stabil dan laluan ke peranti dalam tempoh masa tertentu. Selepas protokol dimulakan semula, peranti persisian membantunya dalam menyegerakkan maklumat (termasuk pelbagai topologi, penghalaan dan maklumat sesi yang diselenggarakan oleh penghalaan/protokol berkaitan MPLS yang menyokong GR), supaya peranti boleh dipulihkan kepada keadaan sebelum dimulakan semula dalam keadaan masa yang sesingkat mungkin. Tidak akan ada laluan mengepak semasa keseluruhan proses mula semula protokol, dan tidak akan ada perubahan dalam laluan pemajuan paket Keseluruhan sistem boleh memajukan data tanpa gangguan. Proses ini dipanggil permulaan semula yang lancar.

nginx smooth restart

Proses Nginx boleh dibahagikan kepada dua jenis: proses utama dan proses pekerja Mula semula lancar dikawal melalui HUB isyarat.

Nota: Pada platform yang mematuhi POSIX, SIGUSR1 dan SIGUSR2 ialah isyarat yang dihantar kepada proses yang mewakili situasi yang ditentukan pengguna.

Untuk menganalisis proses mula semula lancar nginx secara terperinci, kami terus memantau perubahan proses nginx.
Hantar isyarat HUP

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

Dengan memerhati, mulakan semula lancar secara kasar boleh dianalisis Prosesnya ialah:
1. Tuan menggunakan konfigurasi baharu untuk mengeluarkan n-1 pekerja dan tuan baharu
2. Pekerja baharu mengendalikan permintaan baharu, dan pekerja lama keluar selepas pelaksanaan
3. . Induk memuatkan semula konfigurasi, semasa Gunakan induk baharu untuk mengambil alih perkhidmatan
4. Induk dimuatkan dan dikonfigurasikan, dan induk baharu beralih ke mod kerja pekerja
Selepas permulaan semula yang lancar, proses induk nombor tidak akan berubah.

naik taraf lancar nginx

HUP hanya digunakan untuk mulakan semula lancar, konfigurasi memuatkan, dsb. Jika anda ingin menaik taraf versi nginx dengan lancar dan memuatkan semula fail binari yang disusun, anda perlu menggunakan Isyarat USR2.

1. Hantar isyarat USR2

kill -USR2 `cat /home/git/nginx/logs/nginx.pid`

Perhatikan proses nginx dan garpu tuan dan pekerja baharu Kandungan nginx.pid telah berubah, dan fail nginx.pid.oldbin dijana dalam direktori log untuk merekodkan pid induk lama

2 akan menghentikan perkhidmatan dengan anggun Iaitu: berhenti menerima permintaan baharu, tetapi tidak akan menamatkan permintaan yang sedang diproses. Selepas tempoh masa, semua proses pekerja keluar nginx lama, hanya meninggalkan proses induk, dan semua permintaan pengguna diproses oleh proses nginx baharu.

kill -WINCH `cat /home/git/nginx/logs/nginx.pid.oldbin`

3 Hantar isyarat BERHENTI kepada tuan lama, proses nginx lama keluar sepenuhnya, dan peningkatan lancar selesai.

kill -QUIT `cat /home/git/nginx/logs/nginx.pid.oldbin`

FPM smooth restart

FPM (FastCGI Process Manager) digunakan untuk menggantikan kebanyakan fungsi tambahan PHP FastCGI, php5 FPM telah disepadukan sejak .3.3 PHP-FPM boleh dihidupkan dengan menghantar parameter –enable-fpm dalam ./configure.

Mula semula lancar FPM perlu dikawal oleh isyarat USR2, tetapi ia agak berbeza daripada proses mula semula lancar nginx.

kill -USR2 `cat /home/git/php/var/run/php-fpm.pid`

Dengan memerhati proses fpm secara berterusan, kita dapat melihat bahawa FPM dimulakan semula dengan lancar Ia perlu menunggu proses anak keluar sepenuhnya sebelum memulakan proses master dan child yang baharu , dan kemudian tuan lama berhenti.
Gunakan strace untuk analisis lanjut

Didapati tuan memberitahu semua proses anak untuk keluar, termasuk proses anak yang memproses permintaan.

Untuk mengesahkan lagi kesimpulan ini, tulis skrip tidur sebelah pelayan

<?php
exec("sleep 5");
echo &#39;done&#39;;

Gunakan penyemak imbas untuk meminta alamat ini, dan dalam tempoh ini, fpm akan dimulakan semula dengan lancar, dan permintaan akan terus 502.
log ralat nginx:

[error] 29841#0: *1646 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost"

pepijat php#60961, yang juga menerangkan sebab fpm tidak dapat melaksanakan mula semula yang lancar dengan anggun.
Adakah FPM begitu rendah? Jawapannya adalah tidak pada masa itu, sebenarnya, matlamat kami boleh dicapai melalui parameter process_control_timeout.

process_control_timeout

Tetapkan tamat masa untuk proses anak menerima isyarat pemultipleksan proses utama. Unit tersedia: s (saat), m (minit), h (jam) atau d (hari). Unit lalai: s (saat). Lalai: 0 (mati).

Pada dasarnya, php-fpm akan memilih proses fastcgi terbiar untuk memproses permintaan Sebelum memproses, php-fpm akan menghantar isyarat kepada fastcgi untuk menyediakan proses fastcgi untuk menerima pemprosesan permintaan. Walau bagaimanapun, proses fastcgi tidak sentiasa dapat mengendalikan permintaan, iaitu, ia tidak boleh sentiasa bertindak balas kepada isyarat (seperti animasi yang digantung pada masa ini, anda perlu menetapkan masa php-fpm pergi untuk proses fastcgi). bertindak balas kepada isyarat jika masa tamat, php -fpm akan memikirkan cara lain (seperti memilih proses fastcgi lain), ini adalah peranan parameter process_control_timeout.

Nilai lalai parameter ini ialah 0, yang bermaksud ia tidak berkuat kuasa Tukar kepada 10 dan sahkan semula 502 tidak akan muncul lagi.

Atas ialah kandungan terperinci Apakah itu nginx smooth restart dan FPM smooth restart?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!