一次本博客的性能故障排查

无关背景

Ubuntu 10.04 这个版本已经服役两年,虽说是LTS,但最近起发现已经有点力不从心,主要是ppa上一些比较重要的库,如PHP 5.3,ningx的团队已经停止维护,uwsgi则总是落后半年的样子。很大一个原因是这些包在新版的Ubuntu里面已经有官方维护,ppa的第三方维护会缺乏跟进。所以在一定意义上,可以宣布Ubuntu 10.04死亡了。

但Ubuntu的包维护策略就是那样,要么自己维护所有用到的包,要么每隔一段时间就跟着官方一次大升级。觉得不爽就干脆把VPS的系统也改成Archlinux。

现象

一番大迁移后所有的东西都正常上线,但直到一个多星期后的昨天晚上才注意到博客的性能问题。 因为博客那里有nginx直接读取静态的缓冲机制,所以动态执行非常慢之前都没留意到。

把缓冲关闭就非常明显了,任何一次点击的页面都要10秒才能打开。

排查

引起应用缓慢的因素是非常多的,概括来说有两种:IO慢运算慢

运算慢是不大常见的,虽说PHP性能一直受到诟病。但如果是这个问题是很明显的,top里面php的子进程会占满CPU,高居不下。此前排查过一个drupal的站点,是因为前端模板的组件方式存在循环引用,用profile过程看,正则替换的regrex函数占了绝大多的CPU时间。

在SSH看到,打开页面的10秒内php-fpm的子进程基本没占CPU,排除这个可能。

IO慢就复杂了,每个组件都有IO,得先确定IO的范围。

首先想到是数据库Mysql,arch的包太新,有bug?linode主机的磁盘快挂了,磁盘很慢?这些都不好判断,确定这些得借助工具。

Profiling是追踪一个应用的运行流程,记录所有的函数调用栈、记录调用时间的过程,是追查性能问题的最佳帮手。Python里面是有个repoze.profile的wsgi中间件很方便进行排查,但我没做过完整PHP开发,就暂时不大清楚有什么方便的profile方案 (以前弄过早忘了),但google一下还是有很多方案的 ,不过我首先想起newrelic的应用监控系统就提供了这个功能。

Newrelic针对WEB应用和服务器监控服务,其中的服务器监控是免费的,但对应用的监控只有14天试用;所以我赶紧重新申请个帐号,用来监控一下wordpress。安装好监控模块后,超过2s的响应会在他们的Transaction traces记录下来。

newrelic-profile-apt-blog.png

图表数据可以排除数据库问题,几十个数据库的操作都是在ms级别完成,而在apt-blog.net的耗时花了10秒。其实我一开始对这个报告也没看懂,newrelic的直观性还有待提高,其实在这里出现域名的意思是有网络请求,比如askimet的评论、插件的更新等都要和外部请求,这里就会出现域名。

而现在出现了自己博客的域名,那问题就是,程序里面某个地方需要请求自己的域名,可能是检查状态的操作,被卡住了,直到超时才返回。

本机程序访问不到本机,基本确定是iptables规则出问题了,在filter表的最后插入这样一句:

-A INPUT -j LOG

iptables的规则一般是,除非明文允许,否则拒绝,所以经过一系列的规则后如果还没有没ACCEPT的,在最后的都是被DROP了,把这句放最后可以看到究竟是什么包被DROP了。

查看/var/log/everything.log看到这样的记录:

Mar 31 03:17:32 (none) kernel: [17554800.765033] IN=lo OUT= MAC=00:00:00:00:00:0 0:00:00:00:00:00:00:08:00 SRC=106.187.36.50 DST=106.187.36.50 LEN=60 TOS=0x00 PR EC=0x00 TTL=64 ID=31529 DF PROTO=TCP SPT=45594 DPT=80 WINDOW=32792 RES=0x00 SYN URGP=0

这里透露了重要信息:IN=lo SRC=106.187.36.50 DST=106.187.36.50,PHP确实有访问本地网络,送了给lo网卡,SRC和DST都是本地的公网地址。赶紧检查iptables的规则,果然没了对lo设备的允许规则。一般配置机器我都是用记录在自己的Wiki的iptables那套规则的。关于lo的这几句可能一时没仔细想其作用,迁移系统那天脑抽手贱就删掉了。

加入允许lo设备的这句:

-A INPUT -i lo -j ACCEPT

至此,问题解决。

文章分类 Networking, Unix/Linux, 运维技术

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*