Rumah > Artikel > Operasi dan penyelenggaraan > Apakah yang perlu saya lakukan jika nginx melaporkan ralat 502? Perkongsian penyelesaian
Apakah yang perlu saya lakukan jika nginx melaporkan ralat 502? Artikel ini akan membincangkan tentang penyelesaian kepada ralat nginx 502. Saya harap ia akan membantu semua orang!
Proses permintaan http: Dalam keadaan biasa, apabila menyerahkan permintaan dinamik, nginx akan terus memindahkan permintaan ke php-fpm, dan php-fpm kemudiannya akan memperuntukkan php- proses cgi untuk memproses permintaan yang berkaitan, dan kemudian kembali dalam urutan Akhir sekali, nginx menyuapkan hasil kembali ke pelayar klien.
Ralat Nginx 502 Bad Gateway ialah masalah dengan FastCGI
Penyelesaian
Jika anda menghadapi masalah 502, anda boleh memberi keutamaan untuk mengikuti Ikuti dua langkah ini untuk menyelesaikannya.
1 Periksa sama ada bilangan proses FastCGI PHP semasa adalah mencukupi (nilai max_children)
netstat -anpo | grep "php-cgi"| wc -l
Jika "bilangan proses FastCGI" yang digunakan adalah hampir. kepada "Bilangan proses FastCGI" lalai, maka ini bermakna "Bilangan proses FastCGI" tidak mencukupi dan perlu ditambah.
2. Masa pelaksanaan beberapa program PHP melebihi masa menunggu Nginx (php kekurangan memori)
Tingkatkan masa tamat FastCGI dalam fail konfigurasi nginx.conf , contohnya :
fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300;
memory_limit=64M
dalam php.ini, mulakan semula nginx.
Jika masalah tidak dapat diselesaikan selepas pengubahsuaian ini, anda boleh merujuk kepada penyelesaian berikut:
3 max-children and max-requests
Satu nginx php (fpm) xcache sedang berjalan pada pelayan, dengan purata volum lawatan harian kira-kira 300W pv
Situasi sedemikian sering berlaku baru-baru ini: halaman php dibuka dengan sangat perlahan, penggunaan cpu tiba-tiba menurun kepada tahap yang sangat rendah, dan sistem dimuatkan secara tiba-tiba Apabila ia meningkat ke tahap yang sangat tinggi, jika anda menyemak trafik kad rangkaian, anda akan mendapati ia tiba-tiba jatuh ke tahap yang sangat rendah. Keadaan ini hanya berlangsung selama beberapa saat dan kemudian pulih
Menyemak fail log php-fpm mendapati beberapa petunjuk:
Sep3008:32:23.289973[NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200,cur:51200 Sep3008:32:23.290212[NOTICE] fpm_sockets_init_main(), line 371:using inherited socket fd=10,“127.0.0.1:9000″ Sep3008:32:23.290342[NOTICE] fpm_event_init_main(), line 109: libevent:using epoll Sep3008:32:23.296426[NOTICE] fpm_init(), line 47: fpm is running, pid 30587
Sebelum ayat ini, terdapat lebih daripada 1,000 baris penutup Kanak-kanak dan membolehkan log kanak-kanak
Ternyata php-fpm mempunyai parameter max_requests, yang menentukan bilangan maksimum permintaan yang boleh dikendalikan oleh setiap kanak-kanak sebelum ditutup Tetapan lalai ialah 500. Oleh sebab tinjauan pendapat PHP meminta setiap kanak-kanak, dalam keadaan trafik yang padat, setiap kanak-kanak mengambil masa yang lebih kurang sama untuk mencapai max_requests, yang menyebabkan semua kanak-kanak ditutup pada asasnya pada masa yang sama.
Dalam tempoh ini, nginx tidak boleh memindahkan fail php ke php-fpm untuk diproses, jadi cpu akan jatuh ke tahap yang sangat rendah (tidak perlu memproses php, apatah lagi melaksanakan sql), dan beban akan naik ke tahap yang sangat tinggi (tutup dan Hidupkan kanak-kanak, nginx menunggu php-fpm), dan trafik kad rangkaian juga dikurangkan kepada sangat rendah (nginx tidak boleh menjana data untuk dihantar kepada pelanggan)
Tingkatkan bilangan kanak-kanak, dan tetapkan max_requests kepada kurang daripada 0 atau nilai yang agak besar :
Buka /usr/local/php/etc/php-fpm.conf
dan tingkatkan dua parameter berikut (mengikut situasi sebenar pelayan, terlalu besar tidak akan berfungsi)
<valuename=”max_children”>5120</value> <valuename=”max_requests”>600</value>
dan kemudian mulakan semula php-fpm.
5 Tingkatkan kapasiti penimbal
Buka log ralat nginx dan cari mesej ralat seperti "pstream menghantar pengepala terlalu besar semasa membaca pengepala respons dari hulu" . Selepas menyemak maklumat, idea umum ialah terdapat pepijat dalam penimbal nginx Penampan yang diduduki oleh penggunaan halaman laman web kami mungkin terlalu besar. Merujuk kepada kaedah pengubahsuaian yang ditulis oleh orang asing, tetapan kapasiti penimbal ditingkatkan, dan masalah 502 diselesaikan sepenuhnya. Kemudian, pentadbir sistem melaraskan parameter dan hanya mengekalkan dua parameter tetapan: penampan kepala pelanggan dan saiz penimbal fastcgi.
6. request_terminate_timeout
Jika 502 berlaku terutamanya semasa beberapa siaran atau operasi pangkalan data, dan bukannya biasa dalam operasi halaman statik, maka anda boleh menyemak Lihat salah satu daripada tetapan php-fpm.conf: request_terminate_timeout
Nilai ini ialah max_execution_time
, iaitu masa skrip pelaksanaan fast-cgi.
0s bermaksud penutupan, yang bermaksud ia akan berterusan selama-lamanya. (Saya menukar nombor tanpa melihat dengan teliti semasa pemasangan)
Dalam mengoptimumkan fastcgi, anda juga boleh menukar nilai ini selama 5 saat untuk melihat kesannya.
Jika bilangan proses php-cgi tidak mencukupi, masa pelaksanaan php adalah panjang, atau proses php-cgi mati, ralat 502 akan berlaku.
Pengetahuan lanjutan:
Nginx 502 Bad Gateway bermakna PHP-CGI yang diminta telah dilaksanakan, tetapi atas sebab tertentu (biasanya masalah dengan sumber bacaan) PHP -Proses CGI ditamatkan kerana pelaksanaan yang tidak lengkap Secara umumnya, Nginx 502 Bad Gateway berkaitan dengan tetapan php-fpm.conf.
php-fpm.conf mempunyai dua parameter penting, satu ialah max_children dan satu lagi ialah request_terminate_timeout, tetapi nilai ini tidak universal dan perlu dikira sendiri. Apabila masalah 502 berlaku semasa pemasangan dan penggunaan, ia biasanya kerana proses php-cgi lalai ialah 5. Ia mungkin disebabkan oleh proses php-cgi yang tidak mencukupi Anda perlu mengubah suai /usr/local/php/etc/php-. fpm.conf Tingkatkan nilai max_children dengan sewajarnya.
Kaedah pengiraan adalah seperti berikut:
如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就 是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值,这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟-30分 钟都可以。而max_children这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。
按照官方的答案,排查了相关的可能,并结合了网友的答案,得出了下面的解决办法。
1、查看php fastcgi的进程数(max_children值)
netstat -anpo | grep “php-cgi” | wc -l
5(假如显示5)
2、查看当前进程
top观察fastcgi进程数,假如使用的进程数等于或高于5个,说明需要增加(根据你机器实际状况而定)
3、调整/usr/local/php/etc/php-fpm.conf 的相关设置
19b28ecdcb02fd02e7977bafb610285a104b175f9a50d57c75316becd702e959dc46f80ce9d85bf57c6302aebe0e298a8260s4b175f9a50d57c75316becd702e959dc
max_children最多10个进程,按照每个进程20MB内存,最多200MB。request_terminate_timeout执行的时间为60秒,也就是1分钟。
推荐教程:nginx教程
Atas ialah kandungan terperinci Apakah yang perlu saya lakukan jika nginx melaporkan ralat 502? Perkongsian penyelesaian. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!