問題:最近的搶購有點火,到點搶購的時候**就會出現502錯誤 頂不住消費者的壓力。
之前php-fpm配置:
單個php-fpm例項,使用socket方式,記憶體8g 靜態方式,啟動php-fpm程序數300,具體引數如下
listen = /tmp/php-cgi.sock由於架構,**等原因,單台幾百併發就出現502錯誤。#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
增大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啟動php-fpm2即可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
配置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 資料庫 資料庫集群部署,主備設計,讀寫分離,對資料量大讀寫操作頻繁的表...