前言
在分享这个事件前,笔者先和大家一起来了解一下CC * * *:
【CC * * *】
? <强> 者借助代理服务器生成指向受害主机的合法请求,实现DDOS和伪装就叫:CC (ChallengeCollapsar)。
CC主要是用来 强>页面的.CC <强> 的原理就是 强>者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽,一直到宕机崩溃.CC主要是用来* * *页面的,每个人都有这样的体验:当一个网页访问的人数特别多的时候,打开网页就慢了,CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量的CPU时间)的页面,造成服务器资源的浪费,CPU长时间处于100%,永远都有处理不完的连接直至就网络拥塞,正常的访问被中止。
? CC <强> 是DDOS(分布式拒绝服务)的一种,相比其它的DDOS 强> CC似乎更有技术含量一些。这种* * *你见不到真实源IP,见不到特别大的异常流量,但造成服务器无法进行正常连接。
引用百度百科https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545?fr=aladdin
酸爽的时刻
?某天下午正,要到下班点的时候,笔者的手机突然振动一下,打开一看,是一条阿里云发的短信。点进去一看,是公司某个项目中的服务器CPU报警的短信,报警内容震惊了! ! ! ! ! !
在登录集群中其它服务器看一下,也是一样的:
这个项目以php程序为主,所以集群中的服务器除了php-fpm进程大量占用了CPU以外,没看到其它进程占用,注意看上面的运行值,正在运行的进程数量一直居高不下,大量的进程不释放,莫非是调的php进程参数有问题,先来看下php的进程配置:
公司所有的服务器都是标准配置(CPU是16核内存为32 g)。平均一个php-fpm进程占用2米的内存左右,设置最大子进程数量为800个,启动进程为100年,这么计算的话,参数都在合理的范围内,不应该出问题。
<代码>点。max_children=800 # php-fpm最大的子进程数量 点。start_servers=100 #动态方式下的起始php-fpm进程数量 点。min_spare_servers=100 #动态方式空闲状态下的最小php-fpm进程数量 点。max_spare_servers=200 #动态方式空闲状态下的最大php-fpm进程数量代码>
说明:php-fpm进程池开启进程有两种方式,一种是静态的,直接开启指定数量的php-fpm进程,不再增加或者减少;
另一种则是动态的,开始时开启一定数量的php-fpm进程,当请求量变大时,动态的增加php-fpm进程数到上限,当空闲时自动释放空闲的进程数到一个下限。这两种不同的执行方式,可以根据服务器的实际需求来进行调整。
ps,
iostat,
免费的,
iftop,等方式查看进程、io、内存及带宽等情况都没有异常,也没有收到其它的报的警,ecs服务器,slb负载的流量均无异常,奇怪了?
先解决问题,拿一台服务器重启一下nginx, php服务。不行,重启过后还是一样,CPU瞬间满了。会不会php请求复述,服务的时候找不到,一直卡在那里。
登录复述,查看一下,复述,内存,cpu,连接数等使用情况都很稳定,服务器和复述的连通性测了也都好了的:
这个时间点也没有活动啊,赶紧查看下日志吧。