php过载后无法恢复的原因分析
我们的Php-fpm的request_terminate_timeout设置的是5s,于是只要是有请求执行超过5s就会被php-fpm将执行进程干掉,在出问题的前后出现了大量的5s超时,初步猜想可能是因为eaccelerator的共享内存造成的,子进程被干掉时共享内存被写错了,导致所有请求过来都会出错,但是这解释不了新文件也会被卡住的问题,于是去看eacceleraotr的代码,发现如下代码
[cpp]
#define spinlock_try_lock(rw) asm volatile("lock ; decl %0" :"=m" ((rw)->lock) : : "memory")
#define _spinlock_unlock(rw) asm volatile("lock ; incl %0" :"=m" ((rw)->lock) : : "memory")
static int mm_do_lock(mm_mutex* lock, int kind)
{
while (1) {
spinlock_try_lock(lock);
if (lock->lock == 0) {
lock->pid = getpid();
lock->locked = 1;
return 1;
}
_spinlock_unlock(lock);
sched_yield();
}
return 1;
}
static int mm_do_unlock(mm_mutex* lock) {
if (lock->locked && (lock->pid == getpid())) {
lock->pid = 0;
lock->locked = 0;
_spinlock_unlock(lock);
}
return 1;
}
[cpp]
其中mm_mutex是指向共享内存的,也就是说eac用了共享内存来当作进程间的锁,并且使用的spinlock方式,那这样一来一切都能解释的通了。设想如下一种情况,某个进程拿到锁之后被php-fpm干掉了,它没有unlock,这样一来所有的php-fpm子进程都拿不到锁,于是大家就都在这个while(1)循环里卡死了。猜想有了,怎么去证实呢?原来的想法是直接去读那片共享内存,结果发现php时IPC_PRIVATE的,所以没办法读了。于是只能等到线上出问题后gdb上去看内存,今天终于有了确凿的证据
[html]
(gdb) p *mm->lock
$8 = {lock = 4294966693, pid = 21775, locked = 1}
这里可以看到内存已经被进程号为21775的进程拿到了,但事实是,这个进程在很早以前就已经被干掉了。
问题得到证实了,那么再回头看一下这个问题发生的条件
1、请求执行时间很长,长到会被php-fpm干掉
2、进程被干掉时,php正在require文件,并且eac拿到了锁
从这里可以看到,有一些特定情形会将这个概率放大
1、request_terminate_timeout时间很短
2、使用auoload方式,或者在执行逻辑里require文件,因为如果在请求开始前就将所有的文件加载,那除非光require文件就已经超时,否则不应该会在require文件时被干掉。但是同样的使用autload方式也有一个比较丑陋的办法可以避过这个问题,那就是在autload函数里判断一下,如果执行时间过长了就直接exit而不是require
个人觉得,解决这个问题的最好办法是request_terminate_timeout时间设置的足够长,比如30s, 300s,而将超时判断全部放在应用层,不能通过php-fpm来处理这种问题,php-fpm事实只能用作最后一重保险,不得不使用的保险。另外php里还有一个超时设置max_execution_time,但是这个超时在cgi模式下是cpu时间,所以作用不大