几个月前bluehost偶尔会出现超标,当然都不是有意而为,在我的再三邮件请求下,合租的伙伴们越来越乖了,CPU也很正常了,另外还有伙伴考虑到其他兄弟的使用安全,都在谨慎的发表言论,我很是感激,譬如这个伙伴liutianyi.net,考虑到是合租关系,就没有在他的blog上发表敏感的话题,如本文图片,几个月来,我合租的bluehost都很正常,一直未出现超标现象,所以特此向合租伙伴表示感谢,感谢你们的支持。但是有的时候也难免会出现失误,今天第二次的合租服务器就出现超标了,我通过程序的定位找到我原因,当然这个伙伴也给我邮件了,主要原因在于我那个cos-html-cache,在批量重建静态文件的时候数据库查询量暴增,因此会出现超标,这也是我为什么迅速将插件升级到2.0的原因之一。下面详细展示一下定位的步骤。
首先打开定位程序(自己写的文本处理程序,比较简陋和简单),输入密码

进入CPU超标文件列表

根据日期,点击对应的超标log文件

这里可以清楚的看到红色的部分表示CPU的运行时间已经超过30秒,原因是数据库查询超时导致,下面根据程序自动设置好的时间参数,点击确认开始定位数据库的查询
,
程序将列出当天的数据库查询记录,然后点击粗体的日志文件,即可看到数据库的查询记录以及对应的SQL语句,根据数据库名字便可定位到网站,定位结束。

该程序旨在迅速定位,找出CPU超标的原因,不过最近的4个月都没有CPU超标的现象发生,一旦出现超标,我将给你发送邮件,请你检查程序,毕竟大家都不是有意而为,而这次的罪魁祸首在于我的那个cos-html-cache插件,当然使用插件的人也有责任,那就是一次更新的缓存数量太多 。
感谢合租伙伴的配合。
该日志未加标签
前3排已经被占据了 快抢好位置哦
今天留言给你时候 是在你bloggermap.org上看到的[r]是在bloggermap上看到超标的显示还是bloggermap上看到这个文章?[/r]
汗 终于发现原因了 一天带来了20个ip
数据库查询量暴增也会用过CPU?看来我以后要小心了