某个子站是php写的，访问的时候nginx时不时会冒出现502错误，高峰时更频繁，检查php-fpm的日志发现大量的 child exited on signal 7 (sigbus)，并且和accesslog里的502时间完全吻合，排除了php进程过载的可能，然后又排除了apc的嫌疑。
既然php进程是收到信号后死亡的，那么尝试抓些coredump来分析吧：
先设置一下coredump的保存路径，注意要空间够大的地方，因为coredump可能会较多而且很大（比如开了apc设置了1g，那就会有1g）：
#echo /tmp/core.%e.%p.%h.%t > /proc/sys/kernel/core_pattern
然后修改下ulimit，允许coredump：
#ulimit -c unlimited
重启php-fpm。 要不了多久，/tmp/目录里就产生了一堆coredump文件，很好，打包拖回线下来分析吧。 记得关闭coredump，并重启程序：
#ulimit -c 0
分析coredump一般用gdb就够了，（二进制发行版的话，先安装对应的debug symbol包）：
gdb /usr/local/php/sbin/php-fpm core.php-fpm.10375.php.1365314990
执行下bt命令，看下backtrace（具体的信息忘记记录了），发现是挂在lex_scan函数，看了好几个coredump，基本都是挂在lex阶段的函数。
我对php源码没什么研究，上google搜一下“php sigbus lex_scan”，前两名的连接基本就给出了答案：
https://bugs.php.net/bug.php?id=527522010年报的bug，一直没有close，因为看起来这并不是php的bug，仔细看，里面有重现的范例，最后也有人找到了规避办法。
http://zecrazytux.net/troubleshooting/php-sigbus-crash-prestashop此君经历了和我一样的分析过程，并且给出了明确的原因和解决办法。
简单说lex_scan是在对php文件进行语法分析，这个时候正好一个包含的php文件被改写，于是悲剧发生。
为了证实，我用strace跟踪php进程的执行，最后终于抓到了：
11670 lstat(/home, {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
11670 stat(/home/www/cache/default.php, {st_mode=s_ifreg|0644, st_size=68579, ...}) = 0
11670 --- sigbus (bus error) @ 0 (0)
来源：http://blog.druggo.org/post/2013/05/02/%e4%b8%80%e4%be%8bphp%e8%bf%9b%e7%a8%8b%e7%9a%84sigbus%e6%95%85%e9%9a%9c