2010/12/15 22:32:45 [error] 3897#0: *1831129 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.217.163.37, server: xxx.com.cn, request: “GET / HTTP/1.1″, upstream: “fastcgi://127.0.0.1:9000″, host: “xxx.com.cn”, referrer: “http://xxx.com.cn/”

从日志的表示来看应该不是nginx的问题,而是 fast-cgi 执行超时没有及时返回数据到ngnix的问题. 可web和数据库负载都不高,不应该是程序超时的问题. 查资料也没有找到原因,网上于几个人说遇到同样问题,也没有好的解决方案. 后来仔细分析日志,发现出现错误的日志的时间都是大于当前时间,这点很奇怪,难道是系统时间的问题? 后来再仔细查资料,才找到原因. 原来是 centos 的一个内核bug, 调用gettimeofday()这个函数的时候会比当前时间快4398秒.  具体原因是因为多核cpu,各核的TSC不一样造成的.  看来 fast-cgi 应该是调用了这个函数的.

解决方案是升级内核..  相信很多和我一样不是专业sa的兄弟对升级内核之类的事情还是比较犯怵的,不过不用担心有一个不用升级内核的解决方案. 在不升级kernel的情况下，可以考虑修改time source，来解决。修改kernel option。

具体操作如下:

vim /etc/grub.conf

kernel /vmlinuz-2.6.9-1.667 ro root=/dev/hda2 clock=pit (红色部分为新增的)

然后重启服务器,问题解决.  我的产品环境已经3天没有报这个错误了.

感谢一下,优米的SA提供的支持:)

参考资料:

http://blog.chinaunix.net/u/31357/showart_1302796.html
http://tonykorn97.itpub.net/post/6414/456362

天那，google3个月来几乎没怎么抓取我的网站。。。 难怪我的pr从8掉到了7，再回头看看数据统计，更是夸张，下面是从google来访的统计这是怎么回事儿呢？ 基本可以判定是google的爬虫无法访问我的网站，或者访问的过程中遇到了什么障碍。

接下来就是分析问题的原因了

1. 首先查看网站的日志，发现最新的1000条里还有googlebot 造访的记录

2. 用google搜我一直排第一的关键词，结果前10页都没有翻到我，排第一的是一个极其恶心的网站，郁闷。

3. 用google网站管理员工具种的像google bot 一样去抓取功能，抓一下首页，发现失败，看来真的是google无法访问我的网站。

4. 看来要找google访问不了我的原因了，服务器是我独用的，没有其他网站，也没有邮件服务器或者其他，更没有欺骗搜索引擎的脚本，所以ip被google封掉的可能性不大。那就只能说明是我把google的ip封掉了！ 因为之前遭遇cc攻击，写过一个封禁的脚本，自动把访问量超过一定限制的ip用iptables block 掉。

5. 我把 iptables 暂时停用，然后再用google网站管理员工具模拟一下googlebot，神奇的事情发生了，居然立即显示了成功状态和抓取结果。赶紧再查一下日志，发现google是通过 203.208.60.x 这个ip来抓取的。赶紧再去看一下封禁记录，发现这个c段的四五个ip都是在4月份被我的脚本自动封掉的:(  记得我当时还是分析了3个月的googlebot抓取的频率，才设定的每分钟访问动态页面超过150个被视为攻击，脚本跑了一年多，也没见google或者baidu的抓取异常。。。 莫非今年4月份的时候google修改了抓取频率了？

6. 回想起当年写这个脚本的原因，就是在08年底的时候遭遇了恐怖的cc攻击，后来写了脚本防范，为了防止误杀搜索引擎，所以加了 grep -i  ‘xxxx|xxxx’ 的管道，结果这个攻击的人更过分，直接把 refferr 写成和 google bot 一样的方式，几千国外代理一起上来！然后我又改算法。。。。

结果搞清楚了，也可以避免问题的发生了，在这里要提醒做站的朋友，google webmasters 是个好东西，一定要定期查看。写自动封禁的脚本，一定要考虑到搜索引擎误伤问题，千万别犯我一样的错误。

1. 因为需要编译，所以需要gcc环境，不过好在我已经装过xcode了，跳过此步。

2.下载memcache的源码，然后编译配置。。。。 听着麻烦吧，不过有人早就帮忙写好了脚本，从下载到安装完成，执行一下就ok：） 脚本可以从这里下载。 只需要 chmod +x 一下，然后执行就好了。

3. 安装php-memcache扩展, 也简单，下载一个 PHP 5.2.5 (Intel) memcache.so 拷到 /Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-[date] ,   这个 [date]会根据你装的 MAMP 版本不同而不同，不用担心，你一定找得到。

4. 配置 php-memcache 扩展，打开php配置文件： /Applications/MAMP/conf/php5/php.ini 增加一行 extension=memcache.so 就ok了。加哪儿？ 找到类似的行就行了，比如 php-mysql.so 之类的。

5. 重启 MAMP 就ok了， 用 phpinfo() 试一下，应该能看到 memcache 了。

6. 还没完，memcache 装好了，还没启动呢，我是这么启动的 memcached -m 32 -p 11211 -d 。 如果需要可以把这句加到 MAMP 的 startApache.sh 里，这样就可以自动启动了。 当然别忘了在 stopApache.sh 里也加一句 killall memcached.

就这些了：）喝水不忘挖井人，以上主要是从这篇文章学习的。

本来以为是备用服务器的系统有些问题，因为之前跑过一些乱七八糟的应用。昨天修好了服务器，换上线，结果发现问题依旧，流量还是有些高，我晕！

今天终于找到了原因，在缓存服务器上发现，缓存的命中率低了一半，我晕，咋回事儿。看看日志才知道，凡是缓存设置小于5分钟的页面全都是 “TCP_REFRESH_MODIFIED” 状态，我用的是 squid3，之前的版本应该是叫 “TCP_REFRESH_MISS” 。这就很显然了，squid根本没起作用，每次用户访问都去源站取数据去了，难怪源站流量会大。仔细检查过之后才发现，squid服务器和iis服务器之间的时间差了6分钟，也就是说源站的页面被缓存下来的时候就就被认为是过期缓存了，我晕！

把两台机器的系统时间都和标准时间同步一下，问题解决！