Linux
64bit 上的 LAMP 堆棧，16 核機箱消耗 100% CPU
===已解決===
這個問題解決了。事實證明 ImageMagick 在多個 CPU 上存在問題。編譯 ImageMagick 以使用一個 CPU 解決了這個問題。
================
我添加了一個新的 Web 伺服器作為升級，但它在幾秒鐘內就崩潰了。
舊盒子有 8 個 2.33GHz 的 Xeon 核心。新機擁有 16 個 2.40GHz 的 Xeon 核心。新機記憶體分別為8G和32G。
另一個主要區別是從 32 位到 64 位的飛躍。
作業系統都是 CentOS 5.6，Apache 也是 2.2.3-45。
PHP 是 5.2.10 並且是手工編譯的。除了架構位之外，配置選項是相同的。
從所有這些資訊中，您會認為新機器會尖叫，但目前的盒子會處理負載並且偶爾會摔倒。新機器每次都在不到一分鐘的時間內當機。
記憶體很好，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流量通過負載均衡器進入，並在兩者之間以 50/50 的比例分配。當我打開新機器時，負載峰值達到 200，我必須將其關閉，因為它停止接收請求。
針對 httpd 的 strace 似乎沒有什麼啟示，但這是 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========== 編輯/更新 ==========
我發現當我按照建議將負載均衡器上的流量限制為 10% 時，它仍然崩潰。當我用 siege 和 400 連接擊敗它時，它的表現非常好。負載增加但徘徊在 6 左右並滿足所有請求。
我禁用了訪問日誌，但我啟用了一段時間並告訴負載均衡器再次開始發送流量。我讓它執行直到負載達到 200 大約 3 分鐘並保存了日誌。
我解析了日誌以獲取與圍攻一起使用的請求。這會給我一個更準確的基準。
果然，沒有實時數據，只有我點擊它，我將負載飆升到 200。我開始將文件切成兩半並測試上半部分和下半部分。我將繼續此操作，直到找到破壞伺服器的特定請求或請求。
到目前為止，它看起來像是大量使用 ImageMagick 的東西，但我已經將 10K GET 請求減少到 50 個並且仍在繼續。
這不是一個答案，而是一系列幫助您追踪它的步驟。
- 安裝 Ganglia： http: //ganglia.sourceforge.net/。它是我首選的負載故障排除工具。你會喜歡它。
- 看看您是否可以使用負載均衡器將較小百分比的流量（例如 5%）發送到您的新伺服器。這將使您的伺服器有希望保持更長時間。
- 在新伺服器上執行 top 並通過“P”排序鍵按 CPU 排序。看看是什麼佔用了大部分週期。
- 仔細檢查所有與 MySQL 和 Apache 的 PHP 綁定以及庫是否安裝正確。根據您迄今為止提供的資訊，這是我對出了什麼問題的第一個懷疑。您手動編譯 PHP 的事實也引發了潛在的危險信號。仔細檢查您的配置選項，並確保在 32/64 位更改中預期或要求的內容沒有任何變化。
- 啟用並查看日誌：php error_log 和 apache 錯誤日誌以查看發生了什麼。這總是提供資訊，但您需要在特定環境中將信號與雜訊分開。
這些步驟中的一個或多個可能有助於充實問題所在。