某电商网站一严重Bug的解决过程
这家网站目前由本人负责系统维护，刚接手不久。闲话先不多说，讲下Bug的发现过程。
首先打开常用的top命令，不过这里我输入了shift+m指令，也就是让top里的进程列表按进程占用的内存从大到小排列。如下图
http://upload.server110.com/image/20140308/1-14030R31920C9.png
这张图是在问题进程出现的时候截的，所以我们可以看到15149这个进程，图上显示占用的内存为144MB。
类似的进程每隔几分钟就会出现一次，占用内存从十几MB开始不断增加，直至达到memory_limit限制的数值，然后进程消失。
使用命令strace -p 15149，显示的内容如下图
http://upload.server110.com/image/20140308/1-14030R31921X6.png
大概可以看出，程序在不断的查询数据库，仿佛进入了死循环。查询的表名为user，应该是在做和用户信息有关的操作，这条信息在后面会派上用场。
使用命令lsof -p 15149，可以看到下面这些信息
http://upload.server110.com/image/20140308/1-14030R31921920.png
http://upload.server110.com/image/20140308/1-14030R31922D3.png
根据图片显示的信息，可以判断进程正在处理的程序位于360cps目录下。并且，访问这个程序页面的IP为123.*.*.*。
然后根据这个IP地址去检查日志文件，如下图
http://upload.server110.com/image/20140308/1-14030R31922642.png
现在已经清楚了，出现问题的程序页面地址为api_redirect.php。
这家团购网站大部分流量是来自于tuan.360.cn，访客在360网站点击链接后，会打开一个360网站上的程序，这个程序会POST请求本网站的api_redirect.php，请求成功后才会跳转到本网站。
由于请求的方式为POST，而日志里没有办法记录POST的内容，所以，我修改了程序的代码，让程序记录POST数据。如下图。
http://upload.server110.com/image/20140308/1-14030R31923I4.png
采集到的POST数据大概分为二种样本，
第一种：
http://upload.server110.com/image/20140308/1-14030R31923951.png
第二种：
http://upload.server110.com/image/20140308/1-14030R31923401.png
这二者的区别为，第一种是没有在360网站登录的，第二种是在360网站登录过的（有qid和qname，q应该是qihoo的意思）。
而在重复多次前面的检查方式后发现，出现问题的请求，都是在360网站登录过的访客。
已经收集到了足够多的信息，接下来开始审查程序。按程序的执行流程，从头开始看，发现了一处会涉及到用户表的操作（在前面已经通过strace跟踪到进程是在操作user表时出的问题），如下图。
http://upload.server110.com/image/20140308/1-14030R31923G7.png
这个是只有在360网站登录过（有qid）才能进行的操作，从逻辑来看，符合收集到的POST数据后的判断（只有在360网站登录过的访客请求才会出问题）。
继续查找login_auto这段代码，如下图，这里只帖出关键部分
http://upload.server110.com/image/20140308/1-14030R319243S.png
前面我们已经看到，login_auto使用了360网站POST过来的mail地址作为参数，而从我们收集到的POST数据来看，这个mail地址是空的。
所以login_auto方法里赋给$cpsuser_mail这个变量的值就成了类似'_xxxxx'的样子。
我们到数据库去看一下
http://upload.server110.com/image/20140308/1-14030R31924I0.png
可以看到，这样的地址已经排到了快10万个。
也就是说，现在的情况下，这段程序要检查数据库近10万次，才会跳出这个循环，已经和死循环差不多了。
到这里，问题已经完全弄清楚了，接下来的修复工作就简单多了，这里不再作描述。
这个Bug造成的危害十分严重，第一，所有在360登录过的用户都无法跳转到本站，造成大量的流量丢失，对于电商网站，流量就等于$。第二，进程出问题的时候会导致占用大量的内存和CPU，所以，在流量稍大的时候，很容易把服务器拖挂，在接手这个网站时老板曾提到过在双11等活动期间网站频频当机（后来了解到，这个接口已经用了二年多的时间）。
如果你的网站或服务器也需要靠谱的技术支持，请与我联系。
转载请注明来源地址：http://www.server110.com/linux/201403/7498.html
学习了
strace -p 15149
lsof -p 15149 那两个命令确定不错，学习了
也就是 SQL 语句没加 Limit 造成频繁的查询和锁表？ xwmhmily 发表于 2014-06-27 13:53 static/image/common/back.gif
那两个命令确定不错，学习了
也就是 SQL 语句没加 Limit 造成频繁的查询和锁表？代码的逻辑错误，和SQL没什么关系。 数据库线上的环境都比较复杂，移动还有数据库同步问题的呢
页:
[1]