如何面對你 LNMP高併發時502

2021-09-03 09:33:34 字數 2585 閱讀 3322

問題:最近的搶購有點火,到點搶購的時候**就會出現502錯誤 頂不住消費者的壓力。

之前php-fpm配置:

單個php-fpm例項,使用socket方式,記憶體8g 靜態方式,啟動php-fpm程序數300,具體引數如下

listen = /tmp/php-cgi.sock

#listen = 127.0.0.1:9000

listen.backlog = 2048

listen.allowed_clients = 127.0.0.1

pm = static

pm.max_children = 300

pm.start_servers = 50

pm.min_spare_servers = 30

pm.max_spare_servers = 250

request_terminate_timeout = 0

request_slowlog_timeout = 2

由於架構,**等原因,單台幾百併發就出現502錯誤。

增大pm.max_children為400

nginx和fpm 新增了 listen.backlog = 2048

最大開啟檔案控制代碼數 65535

/etc/sysctl.conf 都進行了微調,高併發時nginx發起的連線數,遠遠超過了php-fpm所能處理的數目,導致埠(或socket)頻繁被鎖,造成堵塞。依然出現502錯誤 

終極解決方法:

啟用兩個php-fpm例項,把php-fpm分為兩部分,每部分各聽乙個埠或socket,這樣就減少了lock,依然保持400個php-fpm程序,每個例項啟用200個,採用nginx的upstream負載均衡,輪詢每個socket來處理請求。

具體操作:

cp php-fpm.conf php-fpm2.conf

vi php-fpm2.conf 做相應的修改

[global]

pid = /usr/local/php/var/run/php-fpm2.pid

error_log = /usr/local/php/var/log/php-fpm2.log

log_level = notice

[www]

listen = /tmp/php-cgi2.sock

#listen = 127.0.0.1:9000

listen.backlog = 2048

listen.allowed_clients = 127.0.0.1

pm = static

pm.max_children = 200

pm.start_servers = 50

pm.min_spare_servers = 30

pm.max_spare_servers = 250

request_terminate_timeout = 0

request_slowlog_timeout = 2

slowlog = var/log/slow.log

cp /etc/init.d/php-fpm /etc/init.d/php-fpm2  

vi  /etc/init.d/php-fpm2 

修改prefix=/usr/local/php

exec_prefix=$

php_fpm_bin=$/sbin/php-fpm

php_fpm_conf=$/etc/php-fpm2.conf

php_fpm_pid=$/var/run/php-fpm2.pid

啟動php-fpm2即可

配置nginx

編輯nginx.conf 主配置檔案,如果後端採用虛擬主機,跟我一樣,

新增upstream backend{

server unix:/tmp/php-cgi.sock;

server unix:/tmp/php-cgi2.sock;

vi vhost/test.conf

修改此處 fastcgi_pass  backend; 呼叫fastcgi是,使用負載均衡的方式。

location ~ [^/]\.php(/|$)

try_files $uri =404;

fastcgi_pass  backend;

#       fastcgi_pass  127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi.conf;

# include pathinfo.conf;

重啟nginx。

等待驗證吧,502錯誤會大大地減少,**搶購甚歡,消費者甚歡。

總結: 高併發時使用tcp埠的方式比socket方式相對穩定一點,但是使用埠的方式,處理的效率確實比socket效率低了那麼一點。lnmp環境下,在面對高併發時,除了乙個合理的架構,與合理的調優之外,開發者的**邏輯與高效的**也是影響高併發的乙個重要因素。乙個請求呼叫多少次php-fpm,每個php-fpm處理多少時間,都是開發者需要考慮的點。

如何應對高併發?

參照乙個大佬的文章,我也寫一篇高併發的文章,一下這門高階的現象,以及一些解決措施。乙個關於高併發的問題 那位大佬說 如果真的幹過高併發系統的人,面試官是絕對不會對你提出這個問題的,否則就是他太不明智了。至於為嘛這樣說呢,因為如果設計乙個高併發系統,這句話就是錯誤的了,因為在脫離了業務的系統架構中都是...

高併發,如何提高併發量

一 什麼是高併發 高併發 high concurrency 是網際網路分布式系統架構設計中必須考慮的因素之一,它通常是指,通過設計保證系統能夠同時並行處理很多請求。高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per se...

你如何設計乙個高併發專案?

工作3年左右面試通常會被問到這個問題。我之前也被問到過這個問題,感覺自己回答的點不夠全面,現在重新整理下,包含不限於以下幾點 1 框架設計 對專案拆分成功能單一小專案 參考購物 使用分布式框架,如 dubbo框架,微服務框架。2 資料庫 資料庫集群部署,主備設計,讀寫分離,對資料量大讀寫操作頻繁的表...