64位的LAMP堆栈,16核心的盒子咀嚼了100%的CPU

===解决===

这个问题解决了。 原来ImageMagick在多个CPU上有问题。 编译ImageMagick使用一个CPU解决了这个问题。

================

我添加了一个新的Web服务器作为升级,但它在几秒钟内落下。

旧盒子有2.33GHz的8个Xeon核心。 新机器有2.40GHz的16个Xeon核心。 内存是新机上的8G和32G。

另一个主要区别是从32位跳到64位。

OS是CentOS 5.6,Apache也是2.2.3-45。

PHP是5.2.10和手工编译的。 除了体系结构位之外,configuration选项是相同的。

从所有这些信息,你会认为新的机器会尖叫,但目前的盒子处理负载和偶尔跌倒。 新机器在不到一分钟的时间内就会死亡。

内存不错,I / O好,但是CPU很难挂。 这是从两个mpstat的输出

老盒子

09:14:18 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 09:14:20 PM all 31.34 0.00 2.62 9.68 0.12 1.00 0.00 55.24 11163.50 09:14:20 PM 0 53.00 0.00 5.50 16.00 0.50 6.50 0.00 18.50 10249.50 09:14:20 PM 1 36.68 0.00 2.51 11.06 0.00 0.00 0.00 49.75 126.00 09:14:20 PM 2 17.41 0.00 1.99 7.96 0.00 0.00 0.00 72.64 125.50 09:14:20 PM 3 41.00 0.00 3.00 9.00 0.00 0.00 0.00 47.00 125.50 09:14:20 PM 4 30.00 0.00 2.00 7.50 0.00 0.50 0.00 60.00 143.00 09:14:20 PM 5 28.50 0.00 2.00 12.00 0.00 0.00 0.00 57.50 142.50 09:14:20 PM 6 22.61 0.00 1.51 7.54 0.00 0.00 0.00 68.34 125.50 09:14:20 PM 7 21.50 0.00 2.50 6.50 0.00 0.00 0.00 69.50 125.50 

新箱子

 09:13:41 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 09:13:43 PM all 98.69 0.00 0.81 0.00 0.03 0.47 0.00 0.00 4723.50 09:13:43 PM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1000.50 09:13:43 PM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 2 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 4 98.01 0.00 1.49 0.00 0.00 0.50 0.00 0.00 0.00 09:13:43 PM 5 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 6 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 7 98.51 0.00 1.49 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 8 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 9 99.50 0.00 0.50 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 10 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 11 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 12 95.50 0.00 4.00 0.00 0.00 0.50 0.00 0.00 84.50 09:13:43 PM 13 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 14 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:13:43 PM 15 87.56 0.00 4.98 0.00 0.50 6.97 0.00 0.00 3640.0 

stream量通过负载均衡器进入,两者之间的比例为50/50。 一旦我打开新机器,加载尖峰到200,我不得不把它closures,因为它停止采取要求。

strad反对httpd似乎并没有透露,但这是strace -c -f -p的输出

 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 73.52 2.763912 419 6594 1663 futex 8.65 0.325110 55 5869 4099 open 5.35 0.201250 107 1873 381 stat 3.12 0.117305 67 1748 165 lstat 2.30 0.086434 2010 43 wait4 1.64 0.061543 7 8825 769 read 1.31 0.049158 125 394 clone 0.77 0.028874 53 543 chdir 0.75 0.028356 29 973 munmap 0.34 0.012783 35 370 times 0.30 0.011298 257 44 madvise 0.24 0.008897 7 1312 fstat 0.22 0.008225 1 9341 2 poll 0.18 0.006682 2 2777 14 write 0.14 0.005358 5 1184 mmap 0.13 0.005020 19 262 set_robust_list 0.13 0.004990 3 1688 30 writev 0.13 0.004799 7 671 598 access 0.08 0.003194 0 6531 recvfrom 0.06 0.002404 4 673 8 sendto 0.06 0.002398 4 578 getcwd 0.06 0.002367 5 491 mprotect 0.05 0.002013 4 457 brk 0.05 0.001965 2 883 semop 0.05 0.001924 3 760 lseek 0.04 0.001622 2 845 setitimer 0.04 0.001525 4 412 epoll_wait 0.04 0.001486 1 2595 close 0.04 0.001430 3 412 accept 0.04 0.001429 3 433 231 connect 0.04 0.001388 1 1185 rt_sigaction 0.03 0.000999 2 594 rt_sigprocmask 0.03 0.000963 0 2325 fcntl 0.02 0.000935 1 690 setsockopt 0.01 0.000393 1 534 socket 0.01 0.000380 1 393 12 shutdown 0.00 0.000158 1 127 setuid 0.00 0.000156 0 411 getsockname 0.00 0.000156 2 70 46 unlink 0.00 0.000080 0 254 epoll_ctl 0.00 0.000000 0 64 ioctl 0.00 0.000000 0 38 6 select 0.00 0.000000 0 10 alarm 0.00 0.000000 0 230 getsockopt 0.00 0.000000 0 3 rename 0.00 0.000000 0 22 getrusage 0.00 0.000000 0 127 setgid 0.00 0.000000 0 254 geteuid 0.00 0.000000 0 127 setgroups 0.00 0.000000 0 127 epoll_create ------ ----------- ----------- --------- --------- ---------------- 100.00 3.759359 67166 8024 total 

==========编辑/更新==========

我发现当我按照build议将stream量限制在10%时,它仍然崩溃。 当我用围城和400个连线击败它的时候,它挺好的。 负载增加,但徘徊在6左右,并提供所有请求。

我禁用了访问日志,但启用了一点,并告诉负载平衡器重新开始发送stream量。 我让这个运行,直到加载命中200约3分钟,并保存日志。

我parsing了使用围攻的请求的日志。 这会给我一个更准确的基准。

果然,没有实时数据,只是我打了,我加载到200.我开始砍文件一半,testing上半部分和下半部分。 我继续这样做,直到我可以find特定的请求或中断服务器的请求。

到目前为止,它看起来像大量使用ImageMagick的东西,但是我已经削减了10K GET请求到50,仍然会。

这不会读得太多,而是作为一系列步骤来帮助你跟踪这个问题。

  1. 安装Ganglia: http : //ganglia.sourceforge.net/ 。 这是我的首选负载故障排除工具。 你会喜欢它。
  2. 查看是否可以使用负载平衡器将较小比例的stream量(例如5%)发送到新服务器。 这将让你的服务器希望熬夜。
  3. 在新服务器上运行top,并通过“P”sorting键对CPU进行sorting。 看看大部分的周期是什么。
  4. 仔细检查所有PHP绑定到MySQL和Apache和库安装正确。 这是我的头号嫌疑犯根据您提供的信息到目前为止的错误。 事实上,你手工编译你的PHP也引发了一个潜在的红旗。 仔细检查你的configuration选项,并确保在32/64位更改的预期或要求中没有任何更改。
  5. 启用并查看日志:php error_log和apache错误日志,看看发生了什么。 这总是提供信息,但是您需要将信号从特定环境中的噪声中分离出来。

一个或多个这些步骤可能有助于充实出错的地方。

如果您切换到您的发行版的php或php53包,高CPU使用率仍然发生?

如果您使用的是操作码caching,那么如果禁用它,是否仍然会出现较高的CPU使用率?

如果你运行一个像apachebench这样的工具来对付一个简单的“hello world”PHP脚本而不是实际的应用程序,那么高CPU占用率还是会出现吗?

您可以逐个禁用PHP模块,并testing每个禁用后CPU使用率仍然高吗?

你可以使用PHP分析器/debugging器来分析你的应用程序正在发生什么?