LNMP高并发时502

之前php-fpm配置:

单个php-fpm实例,使用socket方式,内存8G 静态方式,启动php-fpm进程数300,具体参数如下


1

2

3

4

5

6

7

8

9

10

11


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来处理请求。

具体操作:


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27


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=${prefix}

php_fpm_BIN=${exec_prefix}/sbin/php-fpm

php_fpm_CONF=${prefix}/etc/php-fpm2.conf

php_fpm_PID=${prefix}/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处理多少时间,都是开发者需要考虑的点。

时间: 2024-11-03 22:23:48

LNMP高并发时502的相关文章

如何面对你—LNMP高并发时502

问题:最近的抢购有点火,到点抢购的时候网站就会出现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_chil

[转]你如何面对—LNMP高并发时502

From : http://www.topthink.com/topic/5683.html 之前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_childr

大数据量下的高并发分布式访问控制(ACL)优化方案(一)

目前的设计方案 1.1.控制计数: 在目前的项目中,有很多接口需要对访问方进行权限访问控制.目前设计方案是:利用redis集群来存储每个访问控制点的访问计数信息.Key值为=PlatformId(接入平台方)+InterfaceId(系统接口)+dayTime(日期时间),value值为当天每个时段的访问次数统计列表. 1.2.控制规则: 通过页面配置并制定控制规则.业务系统在启动时加载控制规则,并访问redis获取控制次数,然后在业务系统中做逻辑判断完成,ACL控制做请求拦截处理. 目前的痛点

转---高并发Web服务的演变——节约系统内存和CPU

[问底]徐汉彬:高并发Web服务的演变——节约系统内存和CPU 发表于22小时前| 4223次阅读| 来源CSDN| 22 条评论| 作者徐汉彬 问底Web服务内存CPU并发徐汉彬 摘要:现在的Web系统面对的并发连接数在近几年呈现指数增长,高并发成为了一种常态,给Web系统带来不小的挑战.一味地通过增加机器来解决并发量的增长,成本是非常高昂的.结合技术优化方案,才是更有效的解决方法. [导读] 徐汉彬曾在阿里巴巴和腾讯从事4年多的技术研发工作,负责过日请求量过亿的Web系统升级与重构,目前在小

高并发

http://snowolf.iteye.com/blog/1677495 时常看到高并发的问题,但高并发其实是最不需要考虑的东西.为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实你已经在用了.有这个意识就够了,不需要时刻盯着这个问题.只有很少的网站真的能达到高并发. 简单做一个归纳,从低成本.高性能和高扩张性的角度来说有如下处理方案:   1.HTML静态化   2.图片服务器分离   3.数据库集群和库表散列   4.缓存    5.镜像    6.负载均衡;一个典型的使

asp.net解决高并发的方案.[转]

最近几天一直在读代震军的博客,他是Discuz!NT的设计者,读了他的一系列关于Discuz!NT的架构设计文章,大呼过瘾,特别是Discuz!NT在解决高访问高并发时所设计的一系列方案,本人尤其感兴趣.写这篇文章的目的,算是对初次阅读之后的总结备忘吧,以便以后有时间亲自测试,如果能在生产环境中得到应用,那就更有参考价值了. 测试方法:本地模拟测试网站高访问高并发采用的测试工具是大名鼎鼎的Loadrunner,这个工具做测试的一般都知道.在代震军的博客中,有以下几篇介绍了通过Loadrunner

高并发Web服务的演变:节约系统内存和CPU

一.越来越多的并发连接数 现在的Web系统面对的并发连接数在近几年呈现指数增长,高并发成为了一种常态,给Web系统带来不小的挑战.以最简单粗暴的方式解决,就是增加Web系统的机器和升级硬件配置.虽然现在的硬件越来越便宜,但是一味地通过增加机器来解决并发量的增长,成本是非常高昂的.结合技术优化方案,才是更有效的解决方法. 并发连接数为什么呈指数增长?实际上,从这几年的用户基数上看,这个数量并没有出现指数增长,因此它并非主要原因.主要原因,还是web变得更复杂,交互更丰富所导致的. 1. 页面元素增

高并发WEB服务的演变

一.越来越多的并发连接数 现在的Web系统面对的并发连接数在近几年呈现指数增长,高并发成为了一种常态,给Web系统带来不小的挑战.以最简单粗暴的方式解决,就是增加 Web系统的机器和升级硬件配置.虽然现在的硬件越来越便宜,但是一味地通过增加机器来解决并发量的增长,成本是非常高昂的.结合技术优化方案,才是更有 效的解决方法. 并发连接数为什么呈指数增长?实际上,从这几年的用户基数上看,这个数量并没有出现指数增长,因此它并非主要原因.主要原因,还是web变得更复杂,交互更丰富所导致的. 1. 页面元

高并发应用中客户端等待、响应时间的推算,及RT/QPS概念辨析

高并发应用中客户端等待.响应时间的推算,及RT/QPS概念辨析 对于一个网站,已知服务端的服务线程数和处理单个请求所需的时间时,该如何算出高并发时用户从点击链接到收到响应的时间?注意这个时间并不等于服务端处理单个请求的时间,因为高并发时,很多用户请求需要排队等待,你要把这个额外的等待时间算进去. 这个问题很重要,因为它的结果直接影响你的网站的用户体验.这篇文章就是来帮你算这个时间的.你可以使用本文附带的程序来算,也可以通过本文提炼出的公式来算. 另外还有一个问题:所谓RT(响应时间)和QPS,究