前几天才欢天喜地地弄好了新博客，还得到了咪咪、@windyye 和小公主的肯定，正开心着呢，麻烦事情又来了。4号左右的时候忽然发现博客后台各种异常，提交任何东西都容易跑到404页面去，讽刺得是那会儿我刚刚做好自以为比较有趣又新意的404页面。但有时就能成功提交，而另外更多的情况是提交N次后反馈404，但是事实上已经提交成功。但是用户访问就基本没什么问题，但是偶尔还是会出现500的错误，即服务器内部错误。这到底是咋整的呢。
于是开始排查问题，首先怀疑是不是DreamHost的主机又有问题了，因为之前有过宕机的情况。要验证这个想法只需要看看大家有没有问题就好了，比较简单的方法是使用Google Realtime，看看twitter上有没有人抱怨。当然这个是需要Fuck GFW。结果发现很平静，有一两个人在抱怨，但是问题都不一样，看来不是宕机。
这样一来问题一定是局部的了，可能处在自己的程序，也可能是共享服务器的其他网站的事。先去看log文件。SSH去服务器先看了最近的，有大堆的“Premature end of script headers”错误。去网上搜错误成因，基本说得比较多的是因为读写权限设置不当。于是我就去检查里一遍我的各文件、目录的读写情况，文件夹775、文件664，一切正常。
接下来我就开始想我最近新装的插件，感觉一定是哪里有问题，可是插件那么多，我也搞不清是哪一个，就把最近装的全部deactivate，测试，还是差不多；关了皮肤上最原始的，测试，还是跳转404。
没辙了，写了封信给DreamHost的客服请求支援。他们速度还是挺快的，我晚上发的，临睡觉的时候他们就回复了，告诉我他们检查过了，是因为服务器超过了内存使用配额，PHP5.cgi被他们的Process Watcher daemon强行杀掉了。他们建议我关掉一些不必要的插件。可是我已经关了不少了。
我再次想到log，上次只是大致看了下，并没有仔细分析。SSH连上服务器，首先检查一下曾经有哪些异常的IP请求的，用以排除DoS/DDoS。
下面这条命令跟上面的类似，只是统计出最近10,000个请求的IP
找出了点问题，有两三个IP疯狂地访问，一般的IP可能只有150一下，但是这三个少的881，多的1809。我想问题就应该在这里了。用IP Whois查了一下，发现这里头居然有两个是服务器本身（一个IPv4，一个IPv6），还有一个则很有可能是我自己，回想起来我因为要更新日志这两天疯狂得提交来着……自作孽不可活啊……但是那两个自己访问自己的就不太好解释了。继续分析log：
因为我是和朋友公用一个host的，所以我也不排除是他们那边有人黑。上面的第一条命令就是查看多颗域名下访问最高的IP的。结果不吃惊，还是刚刚的结果。上面的第二天命令是看不同域名的traffic统计，还是我的最多，并且发现朋友的几个网站都没有访问了，估计是关了……
再看看是哪些东西被呼叫得比较多：
awk '{print $7}' access.log|cut -d? -f1|sort|uniq -c|sort -nk1|tail -n10
反馈的信息是*最多，1472次，而拍第二位的脚本只有474次，我不太清楚*表示什么，或许是其他的总和，也有可能是指是系统资源，比如cron。
下面开始整理一下现在已经知道信息，我差不多知道是哪里的问题了，分析如下：首先问题在我的PHP代码里面，而且是最近才出现的，那多半是插件，而既然影响到后台了，那应该是个很耗内存资源的插件插件了。范围一下子就缩小了，因为一般装饰类的插件不可能多耗资源，我一下子想到了是我最近装的W3 total cache。它的工作原理就是要是不是把一些页面存下来然后又用户请求的时候就直接回馈，用来提高速度。去设置里使劲仔细地找，看看有什么蛛丝马迹，在Page Cache Settings的Cache Preload里发现了这句话：“Limit the number of pages to create per batch. Fewer pages may be better for under-powered servers.”默认值是10。我想很有可能与这个有关，因为他是通过cron来实现定时任务的，所以这才会使得我即使停掉了所有的插件都还不行，因为很有可能当时cron任务还在进行。当即将他调到3，并且耐心等一下再去测试。
服务器好了不少，现在我再去用上面的几条命令去查看访问量和被叫次数，数字都变得很小，都只有250左右。相信问题应该是解决得差不多了，虽然偶尔还是会有404页面跳出来，但是相信过一阵就好了吧，如果还是不行再进一步调小那个数值或调高刷新间隔。
Case Closed.
补充：
今天DH的另一个工程师联系我，说帮我把DB里的empty space清除了一下，问我有没有什么好转。我转了一圈，没变化，还是有404的错误。就把我的想法回复了她。
另外，今天拿到了昨天的User Resource Report，稍微分析了下：
发现php5.cgi的配额使用率达到99.151%，感觉有点大，觉得很有可能是某plugin的问题。
后来我又找了一份配置W3TC的教程对着弄了一遍，希望有更好的好转。
–EOF–
