标签：style http io sp strong 文件 数据 on 2014
某天，某dz论坛整站垮掉，事后分析：遭遇cc攻击，非常多的肉机（不同IP）对该论坛某个特定的url进行访问，造成整站瘫痪。
教训：
如果遇到整站瘫痪，我们应该怎么办？
1，测试静态页面，检测web-server是否正常，通常是正常的
2，测试php页面，检测php是否正常，两种状态都有可能，大部分是正常的，少数情况异常
3，手工连接数据，测试连通性，执行show processlist，查慢sql
4，查access-log，慢请求肯定会在access-log中体现，这个很重要
因为请求慢才会造成后续请求阻塞进而出现问题，如果请求足够快就不会产生等待，不会阻塞php进程。
请求慢的原因
可能1：php跑满了，请求被饿死（深层原因还是请求慢，这是表象）；
可能2：应用程序内部逻辑问题，有互锁，死循环，函数处理慢要优化（注意，内存溢出不属于此类）；
可能3：io阻塞（写文件慢，目前未碰到过），sql慢（因为sql必须等待执行结束才会返回，未结束会一直等待，即使客户端主动断开，mysql有可能还会一直执行，sql慢是碰到最多的，一旦整站出问题，肯定是因为mysql）
另，内存溢出一定会报php错误，会被记录在php错误日志中，会返回500的错误，只会影响单次执行，不会影响后续请求。
怀疑点：对于一个执行时间很长的php进程，是否会有access-log呢？
access-log已经多次为排查事故原因做出了贡献，我们根据access-log来还原下这次cc攻击下webserver和系统的表现。
攻击开始，少量攻击请求被处理，请求能被响应。很不幸，这个没有发生
1，攻击开始，大量的攻击请求打过来，瞬间塌陷，响应全部超过30秒，返回499状态码
a：10:45:48到10:46:50，单台机器的攻击请求数是50个/秒，从第一秒开始所有php请求均响应失败返回499（30秒超时客户端主动断开连接），图片请求正常，status也返回499（设定的是5秒超时）。这段时间内lvs已经知道前端机无法响应php请求了，但是没做下线处理
b：10:46:50，lvs认为前端机确实有问题，执行下线操作，一直到10:51:13才有新的请求。在此期间，一直有status心跳探测。我们看到了这样的日志：
[30/Oct/2014:10:46:56 +0800] "GET /status.php HTTP/1.1" 504 182 "-" "-" 50 60.002 -
[30/Oct/2014:10:46:56 +0800] "GET /thread-3029964-1-1.html HTTP/1.1" 504 ... 60
[30/Oct/2014:10:46:56 +0800] "GET /status.php HTTP/1.0" 499 0 "-" "KeepAliveClient" 82 5.000 -
分析：第三条日志，5秒+499，是正常的status脚本检测，超时时间是5秒；
第一条日志为什么会是60秒超时呢，解释如下：
同时，注意到status.php在10:46:39有条日志， "GET /status.php HTTP/1.1" 504 182 "-" "-" 50 60.003
合理的解释：已经被php接收，但是一直无法得到执行，被卡死，php设置的执行超时60秒到期后退出。（access-log是在执行结束后记录的，实际请求时间=日志时间减去执行时间）
那么这样就容易解释第二条日志了，和第一条日志一样，到了php执行队列，但被饿死。可以看到，超时时间是60秒，请求时间是10:45:56，请求是在cc攻击之后发生的，cc攻击之后php分两部分，一部分（猜测没有进入php执行队列）被客户端断开返回499，另一部分（进入了php执行队列）被调度和饿死返回504。
标签：style http io sp strong 文件 数据 on 2014
原文地址：http://www.cnblogs.com/helww/p/4078256.html
