Mari kita bincangkan tentang mula semula lancar nginx dan mulakan semula lancar FPM

Artikel ini akan memperkenalkan anda untuk smooth restart dan memperkenalkan nginx smooth restart dan FPM smooth restart secara terperinci.

Graceful Restart

GR ialah singkatan dari Graceful Restart, yang memastikan perkhidmatan pemajuan 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 menyegerakkan maklumat (termasuk pelbagai topologi, penghalaan dan maklumat sesi yang diselenggarakan oleh penghalaan/protokol berkaitan MPLS yang menyokong GR), memulihkan peranti kepada keadaan sebelum dimulakan semula dalam masa yang sesingkat mungkin. negeri. 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.

mula semula lancar nginx

Proses nginx dibahagikan kepada proses utama induk dan proses pekerja pekerja Mula semula lancar nginx dikawal oleh isyarat HUB.

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, anda boleh menganalisis anggaran Proses mula semula yang lancar ialah:
1 Master menggunakan konfigurasi baharu untuk mengeluarkan pekerja n-1 dan master baharu
2. Pekerja baharu memproses permintaan baharu, dan pekerja lama keluar selepas pelaksanaan
3. Induk memuatkan semula konfigurasi Dalam tempoh ini, induk baharu digunakan untuk mengambil alih perkhidmatan
4. Induk dimuatkan dan dikonfigurasikan, dan induk baharu beralih ke mod kerja pekerja
Selepas lancar. mulakan semula, nombor proses induk 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, muat semula fail binari yang disusun memerlukan bantuan isyarat USR2.

1. Hantar isyarat USR2

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

Perhatikan proses nginx, garpu tuan dan pekerja baru, Di kali ini, kandungan nginx.pid telah berubah, dan fail nginx.pid.oldbin dijana dalam direktori log untuk merekodkan pid induk lama

2. dan pekerja nginx akan berhenti dengan anggun Perkhidmatan, iaitu, berhenti menerima permintaan baharu, tetapi tidak 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 PHP Kebanyakan fungsi tambahan FastCGI telah disepadukan dengan FPM sejak php5.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 meneruskan pemerhatian proses fpm, kita dapat melihat bahawa FPM dimulakan semula dengan lancar dan perlu menunggu proses anak keluar sepenuhnya sebelum memulakan master baru dan proses kanak-kanak.
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;;

用浏览器请求这个地址，并在此期间平滑重启fpm，请求直接502了。
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"

php bug#60961，也有对fpm无法优雅的实现平滑重启的说明。
难道FPM这么low？答案当时是no，实际上通过 process_control_timeout 参数可以实现我们的目标。

process_control_timeout

 设置子进程接受主进程复用信号的超时时间。可用单位：s（秒），m（分），h（小时）或者 d（天）。默认单位：s（秒）。默认值：0（关闭）。

 原则上，php-fpm会选择空闲的fastcgi进程去处理请求，在处理之前，php-fpm会给fastcgi发送信号，用来让fastcgi进程准备好接受请求处理。但是fastcgi进程并不总是能够处理请求，也就是不能总是响应该信号（比如出现假死的情况），这时候就需要设定php-fpm留给fastcgi进程响应信号的时间，如果超时了，php-fpm会想其他办法（例如选择其他fastcgi进程），这个就是process_control_timeout参数的作用。

 这个参数缺省是 0，也就是不生效，修改为10，重新验证，502已经不会再出现。

 结论：缺省情况下，PHP-FPM 无法保证平滑的执行 reload 操作，必须设置一个合理的 process_control_timeout 才行，同时需要注意的是其值不能设置的过大，否则系统可能出现严重的请求堵塞问题。

推荐学习：《PHP视频教程》

Atas ialah kandungan terperinci Mari kita bincangkan tentang mula semula lancar nginx dan mulakan semula lancar FPM. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!