这家网站目前由本人负责系统维护,刚接手不久。闲话先不多说,讲下Bug的发现过程。
首先打开常用的top命令,不过这里我输入了shift m指令,也就是让top里的进程列表按进程占用的内存从大到小排列。如下图
这张图是在问题进程出现的时候截的,所以我们可以看到15149这个进程,图上显示占用的内存为144MB。
类似的进程每隔几分钟就会出现一次,占用内存从十几MB开始不断增加,直至达到memory_limit限制的数值,然后进程消失。
使用命令strace -p 15149,显示的内容如下图
大概可以看出,程序在不断的查询数据库,仿佛进入了死循环。查询的表名为user,应该是在做和用户信息有关的操作,这条信息在后面会派上用场。
使用命令lsof -p 15149,可以看到下面这些信息
根据图片显示的信息,可以判断进程正在处理的程序位于360cps目录下。并且,访问这个程序页面的IP为123.*.*.*。
然后根据这个IP地址去检查日志文件,如下图
现在已经清楚了,出现问题的程序页面地址为api_redirect.php。
这家团购网站大部分流量是来自于tuan.360.cn,访客在360网站点击链接后,会打开一个360网站上的程序,这个程序会POST请求本网站的api_redirect.php,请求成功后才会跳转到本网站。
由于请求的方式为POST,而日志里没有办法记录POST的内容,所以,我修改了程序的代码,让程序记录POST数据。如下图。
采集到的POST数据大概分为二种样本,
第一种:
第二种:
这二者的区别为,第一种是没有在360网站登录的,第二种是在360网站登录过的(有qid和qname,q应该是qihoo的意思)。
而在重复多次前面的检查方式后发现,出现问题的请求,都是在360网站登录过的访客。
已经收集到了足够多的信息,接下来开始审查程序。按程序的执行流程,从头开始看,发现了一处会涉及到用户表的操作(在前面已经通过strace跟踪到进程是在操作user表时出的问题),如下图。
这个是只有在360网站登录过(有qid)才能进行的操作,从逻辑来看,符合收集到的POST数据后的判断(只有在360网站登录过的访客请求才会出问题)。
继续查找login_auto这段代码,如下图,这里只帖出关键部分
前面我们已经看到,login_auto使用了360网站POST过来的mail地址作为参数,而从我们收集到的POST数据来看,这个mail地址是空的。
所以login_auto方法里赋给$cpsuser_mail这个变量的值就成了类似'_xxxxx'的样子。
我们到数据库去看一下
可以看到,这样的地址已经排到了快10万个。
也就是说,现在的情况下,这段程序要检查数据库近10万次,才会跳出这个循环,已经和死循环差不多了。
到这里,问题已经完全弄清楚了,接下来的修复工作就简单多了,这里不再作描述。
这个Bug造成的危害十分严重,第一,所有在360登录过的用户都无法跳转到本站,造成大量的流量丢失,对于电商网站,流量就等于$。第二,进程出问题的时候会导致占用大量的内存和CPU,所以,在流量稍大的时候,很容易把服务器拖挂,在接手这个网站时老板曾提到过在双11等活动期间网站频频当机(后来了解到,这个接口已经用了二年多的时间)。
如果你的网站或服务器也需要靠谱的技术支持,请与我联系。
转载请注明来源地址:
http://www.server110.com/linux/201403/7498.html
-------------------------
引用第1楼林沐雨于2014-03-09 12:28发表的 Re某电商网站一严重Bug的解决过程 :
加个索引的事,说的这么复杂
什么10万次![]()
-------------------------
引用第7楼kideny于2014-03-09 20:19发表的 :
图片全挂了。![]()
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。