当前位置:首页 > 运维 > 正文内容

记一次laravel项目因session导致cpu过高的问题

phpmianshi5个月前 (05-26)运维230

问题起因:


腾讯云监控CPU过高报警  10:20-10:28左右持续 百分之80以上。


问题排查:


1. 查看php-fpm慢日志发现有大量如下日志:

[26-May-2020 10:20:36]  [pool www] pid 7368
script_filename = /data/nginx/webroot/simulation-strategy-20200519-203518-1fe2f1
4c/public/index.php
...省略...
[0x00007ffd04de1440] ???() /data/nginx/webroot/simulation-strategy-20200519-2035
18-1fe2f14c/vendor/laravel/framework/src/Illuminate/Session/FileSessionHandler.p
hp:109
[0x00007f00b421d9e0] gc() /data/nginx/webroot/simulation-strategy-20200519-20351
8-1fe2f14c/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSessi
on.php:134
[0x00007f00b421d900] collectGarbage() /data/nginx/webroot/simulation-strategy-20
200519-203518-1fe2f14c/vendor/laravel/framework/src/Illuminate/Session/Middlewar
e/StartSession.php:61
...省略...


2.大概是因为session gc的时候过慢问题,查看时间分布

grep -E '26-May-2020|collectGarbage' php-slow.log|grep collectGarbage -B 1 | grep '26-May-2020'

发现CPU过高的时间段和这个报错非常吻合,持续观察11:32左右又有几个报错,看监控显示11:32确实有CPU过高的情况,基本确定是这里的问题


问题分析和解决:


查看.env文件里session的存储方式设置的是file,打开config/session.php

'lifetime' => 120,
'expire_on_close' => false,

expire_on_close设置为false,意味着用户关闭浏览器时没有删除session,这里我们改为true


cd storage/framework/sessions
ls -alh |wc -l

发现有11236条记录,gc查找文件过慢,删除所有文件再观察(切记不能删除sessions文件夹,否则会出错


当然最根本的还是要把session存入redis或者mc中最好。

版权声明:本文由PHP面试资料网发布,如需转载请注明出处。
分享给朋友:

相关文章






TCP(Transmission Control Protocol) 传输控制协议

三次握手

TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:

SYN(synchronous建立联机) 同步报文段

ACK(acknowledgement 确认)

PSH(push传送)

FIN(finish结束) 结束报文段

RST(reset重置) 复位报文段

URG(urgent紧急) 紧急指针

Sequence number(顺序号码)

Acknowledge number(确认号码)

客户端TCP状态迁移:

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

服务器TCP状态迁移:

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED


各个状态的意义如下: 

LISTEN - 侦听来自远方TCP端口的连接请求; 

SYN-SENT -在发送连接请求后等待匹配的连接请求; 

SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认; 

ESTABLISHED- 代表一个打开的连接,数据可以传送给用户; 

FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;

FIN-WAIT-2 - 从远程TCP等待连接中断请求; 

CLOSE-WAIT - 等待从本地用户发来的连接中断请求; 

CLOSING -等待远程TCP对连接中断的确认; 

LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认; 

TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认; 

CLOSED - 没有任何连接状态;


TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接,如图1所示。

(1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。

(2)第二次握手:服务器B收到SYN包,必须确认客户A的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。

(3)第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK(ACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。

完成三次握手,客户端与服务器开始传送数据。

确认号:其数值等于发送方的发送序号 +1(即接收方期望接收的下一个序列号)。

图1 TCP三次握手建立连接  


TCP协议中的三次握手和四次挥手

理解:窗口和滑动窗口TCP的流量控制TCP使用窗口机制进行流量控制什么是窗口?连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端接收方发送的确认信息中包含了自己剩余的缓冲区...


1、应用程序中调用read() 方法,这里会涉及到一次上下文切换(用户态->内核态),底层采用DMA(direct memory access)读取磁盘的文件,并把内容存储到内核地址空间的读取缓存区。

2、由于应用程序无法读取内核地址空间的数据,如果应用程序要操作这些数据,必须把这些内容从读取缓冲区拷贝到用户缓冲区。这个时候,read() 调用返回,且引发一次上下文切换(内核态->用户态),现在数据已经被拷贝到了用户地址空间缓冲区,这时,如果有需要,应用程序可以操作修改这些内容。

3、我们最终目的是把这个文件内容通过Socket传到另一个服务中,调用Socket的send()方法,这里又涉及到一次上下文切换(用户态->内核态),同时,文件内容被进行第三次拷贝,被再次拷贝到内核地址空间缓冲区,但是这次的缓冲区与目标套接字相关联,与读取缓冲区没有半点关系。

4、send()调用返回,引发第四次的上下文切换,同时进行第四次的数据拷贝,通过DMA把数据从目标套接字相关的缓存区传到协议引擎进行发送。

"在整个过程中,过程1和4是由DMA负责,并不会消耗CPU,只有过程2和3的拷贝需要CPU参与


如果在应用程序中,不需要操作内容,过程2和3就是多余的,如果可以直接把内核态读取缓存冲区数据直接拷贝到套接字相关的缓存区,是不是可以达到优化的目的?

Linux中nio的实现原理

我们上一篇文章 《linux中netstat和ss命令详解》中提到了nio 原文:https://phpmianshi.com/?id=105有一些小伙伴私信想了解什么是nio,我们这篇详细介绍下什么...

负载均衡工作模式以及工作原理

负载均衡的多种解决方案:HTTP重定向当用户发来请求的时候,Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url,然后浏览器再继续请求这个新url,实际上就是页面重定向。通过...

linux中sed用法读这一篇就够了

1.概念sed是一种行编辑器,它一次处理一行内容。处理时,把 当前处理的行存储在临时缓冲区中,称为“模式空间”(pattern space),接着用sed命令处理缓冲区中的内容,处理完成后,把缓冲区的...

linux中如何排查负载过高的问题

概况Linux的负载高,主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多,都将导致服务器负载的急剧攀升。如何判断系统是否已经Over Loadw、uptime、top 等命令都可以...

linux中nf_conntrack table full dropping packet问题处理

概述:在日常的服务器运维过程中,发现某段时间 /var/log/messages日志报错nf_conntrack:table full,drop packet简介:nf_connt...

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。