如何解決 PHP、MySQL 和通用 I/O 的性能問題
我有一個在共享主機上執行的基於 WordPress 的網站。它的響應時間非常不錯（檢索 HTML 頁面大約需要 2 秒，載入所有資源大約需要 5 秒）。
我正計劃將它移動到一個專用的虛擬伺服器（Ubuntu 12.04 LTS）上，理論上它應該會改進一些東西，並使它們更加一致，因為它沒有共享。但是我觀察到性能嚴重下降，生成頁面需要 10 秒。
我通過
/etc/hosts在伺服器上進行編輯並將域映射到127.0.0.1. 我使用 Apache 負載測試器ab來獲取 HTML，因此 JS、CSS 和圖像都被排除在外。還是用了10秒。我在也使用 MySQL 的伺服器上安裝了 Zpanel，它的頁面出現得非常快（1.5 秒）和 phpMyAdmin。直接通過 phpMyAdmin 對 wordpress 數據庫執行一些查詢也可以很快返回它們，查詢時間在 10 到 30 毫秒之間。
記憶體也足夠了，可用的 1Gb 物理記憶體中僅使用了 800Mb，因此這似乎也不是交換問題。我還安裝了 APC 以嘗試提高 PHP 性能，但沒有任何效果。
我還應該尋找什麼？什麼可能導致性能下降？由於我在基於雲的虛擬伺服器上執行，這可能是某種 I/O 問題嗎？
我希望能夠向我的提供者提出這個問題，但沒有顯示來自某些診斷的實際數據，我擔心他只會責怪我的應用程序。
當我發出 HTTP 請求時，更新
sar輸出（每秒）：02:31:29 CPU %user %nice %system %iowait %steal %idle 02:31:30 all 0.00 0.00 0.00 0.00 0.00 100.00 02:31:31 all 2.22 0.00 2.22 0.00 0.00 95.56 02:31:32 all 41.67 0.00 6.25 0.00 2.08 50.00 02:31:33 all 86.36 0.00 13.64 0.00 0.00 0.00 02:31:34 all 75.00 0.00 25.00 0.00 0.00 0.00 02:31:35 all 93.18 0.00 6.82 0.00 0.00 0.00 02:31:36 all 90.70 0.00 9.30 0.00 0.00 0.00 02:31:37 all 71.05 0.00 0.00 0.00 0.00 28.95 02:31:38 all 14.89 0.00 10.64 0.00 2.13 72.34 02:31:39 all 2.56 0.00 0.00 0.00 0.00 97.44 02:31:40 all 0.00 0.00 0.00 0.00 0.00 100.00 02:31:41 all 0.00 0.00 0.00 0.00 0.00 100.00更新 2在 josten 的建議之後。
輸入/輸出：
iotop失敗，OSError: Netlink error: No such file or directory (2)也sar -d失敗了Requested activities not available in file /var/log/sysstat/sa14。我想這是因為這是一個虛擬機，就像iostat也失敗了。難道這就是為什麼%iowait報告的sar 1 10總是0％的原因嗎？CPU負載：
超過 CPU% 的程序
htop實際上是**apache2**. 我期待這可能是數據庫，但它不是。當我執行新的 HTTP 請求時，它會在幾秒鐘內上升到 94%。看來這就是罪魁禍首。我做了
strace -f -t一個總結strace -c -f。似乎有很多lstat呼叫（57786），其中 2455 導致錯誤。不知道這是否正常。除此之外，最重要的電話是wait4我認為是正常的（它只是在等待），並且munmap. 以下前 5 名。% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 51.06 0.124742 897 139 6 wait4 14.90 0.036388 1 57786 2455 lstat 9.67 0.023622 13 1857 munmap 7.69 0.018790 37 514 brk 6.70 0.016361 481 34 clone 2.87 0.006999 74 94 12 select
strace它本身使 apache 的速度降低了 2 倍。我現在正試圖了解長跟踪，看看是否有任何跡象表明是什麼導致 CPU 飆升了幾秒鐘。
lstat性能良好的伺服器的典型時間是什麼？我希望收集一些資訊，以便如果是儲存訪問故障，我可以以建設性的方式向提供商投訴。更新
fio隨機讀取測試的輸出：random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1 fio 1.59 Starting 1 process random-read: Laying out IO file(s) (1 file(s) / 128MB) Jobs: 1 (f=1): [r] [100.0% done] [12185K/0K /s] [2975 /0 iops] [eta 00m:00s] random-read: (groupid=0, jobs=1): err= 0: pid=24264 read : io=131072KB, bw=10298KB/s, iops=2574 , runt= 12728msec clat (usec): min=119 , max=162219 , avg=380.34, stdev=957.37 lat (usec): min=119 , max=162219 , avg=380.89, stdev=957.40 bw (KB/s) : min= 7200, max=13424, per=99.89%, avg=10285.72, stdev=1608.68 cpu : usr=2.80%, sys=18.65%, ctx=33511, majf=0, minf=23 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w/d: total=32768/0/0, short=0/0/0 lat (usec): 250=45.57%, 500=37.17%, 750=3.41%, 1000=7.83% lat (msec): 2=5.67%, 4=0.27%, 10=0.08%, 20=0.01%, 250=0.01% Run status group 0 (all jobs): READ: io=131072KB, aggrb=10297KB/s, minb=10545KB/s, maxb=10545KB/s, mint=12728msec, maxt=12728msec我現在唯一的提示是，
fio與其他系統相比，輸出的 CPU 行似乎顯示出相當多的活動。我在本地 Ubuntu 機器上執行它，輸出為：cpu : usr=0.19%, sys=0.59%, ctx=32923, majf=0, minf=23這個
usr百分比似乎只是我伺服器上報告的一小部分。更新重新 PHP APC。是的，它已安裝。phpinfo 的輸出：
APC Support enabled Version 3.1.7 APC Debugging Disabled MMAP Support Enabled MMAP File Mask no value Locking type pthread mutex Locks Serialization Support php Revision $Revision: 307215 $ Build Date May 2 2011 19:00:42我應該檢查任何特定設置嗎？這些是我的設置（本地值，主值）：
apc.cache_by_default On On apc.canonicalize On On apc.coredump_unmap Off Off apc.enable_cli Off Off apc.enabled On On apc.file_md5 Off Off apc.file_update_protection 2 2 apc.filters no value no value apc.gc_ttl 3600 3600 apc.include_once_override Off Off apc.lazy_classes Off Off apc.lazy_functions Off Off apc.max_file_size 1M 1M apc.mmap_file_mask no value no value apc.num_files_hint 1000 1000 apc.preload_path no value no value apc.report_autofilter Off Off apc.rfc1867 Off Off apc.rfc1867_freq 0 0 apc.rfc1867_name APC_UPLOAD_PROGRESS APC_UPLOAD_PROGRESS apc.rfc1867_prefix upload_ upload_ apc.rfc1867_ttl 3600 3600 apc.serializer default default apc.shm_segments 1 1 apc.shm_size 32M 32M apc.slam_defense On On apc.stat On On apc.stat_ctime Off Off apc.ttl 0 0 apc.use_request_time On On apc.user_entries_hint 4096 4096 apc.user_ttl 0 0 apc.write_lock On On更新增加到96M
apc.shm_size。記憶體完整計數現在為 0，並且在多次刷新網站後，有 96.5% 的記憶體命中率。APC 記憶體使用量為 25.4MB。它似乎已經將載入時間減少了 3 秒左右，如果我
wget從伺服器本身進行純操作而不獲取任何圖像等，現在可以減少到 4 到 5 秒左右。仍然比其他主機慢兩倍以上，但絕對是改進。我仍然覺得奇怪，為什麼在伺服器完全空閒時渲染這些頁面需要這麼長時間（我的開發 PC 上沒有安裝 APC，它也沒有那種行為）。那些額外的剩餘時間被浪費了仍然很奇怪。
這看起來就像我看到的其他情況，Apache 花費大量時間編譯 PHP。您是否確定安裝了操作碼記憶體（例如 APC）？
phpinfo()如果有幫助，它將在 的輸出中顯示為已載入的模組。否則，要跟踪 Apache 在 mod_php 中所做的事情，最好的選擇是 XHProf。對於除 jbx 以外的任何人通過 Google 到達這裡：順便說一下，其他答案非常好。去閱讀它們。但是這些答案，以及 jbx 對他們的回應，幫助我得出了這個結論。