WordPressがとても重くて困りました。環境はCentOSです。監視ツールが入っていないので何がおきているかわからんまん(☝ ՞ਊ ՞)☝
最初の予想
そもそも1日10アクセスとかで大してアクセスがあるサイトではないです。そのため、アクセスによる負荷で重くなったことは考えにくく、PHPかWordPressが原因により、メモリリークをしたか、もしくはApacheの設定がだめでメモリが足りなくなったことにより、スワップがでて遅くなっていると予想しました。
topコマンドでload averageの確認
topコマンドからMをおすとメモリでソートされます。
top
top - 23:16:01 up 340 days, 2:13, 2 users, load average: 0.00, 0.05, 0.16
Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.3%us, 2.3%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1020228k total, 343476k used, 676752k free, 8380k buffers
Swap: 2097144k total, 82072k used, 2015072k free, 56332k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21964 apache 20 0 291m 47m 3608 S 0.0 4.8 0:00.33 httpd
21970 apache 20 0 360m 43m 3996 S 0.0 4.3 0:00.48 httpd
21968 apache 20 0 286m 42m 3596 S 0.0 4.3 0:00.35 httpd
21966 apache 20 0 282m 38m 3616 S 0.0 3.9 0:00.35 httpd
16824 mysql 20 0 1152m 10m 2944 S 0.0 1.1 34:19.43 mysqld
21962 root 20 0 252m 9624 4836 S 0.0 0.9 0:00.02 httpd
21971 apache 20 0 252m 8024 2584 S 0.0 0.8 0:00.00 httpd
21969 apache 20 0 252m 6396 1524 S 0.0 0.6 0:00.00 httpd
略
load averageは0.1にも満たず大したことがありません。95.3%idとなりidleがほぼ100%なのでCPUには余裕があります。つまり現在サーバーは重くないはずです。WordPressは重いですが。
freeコマンド
freeコマンドを試しました。
free
total used free shared buffers cached
Mem: 1020228 274036 746192 96 8328 56048
-/+ buffers/cache: 209660 810568
Swap: 2097144 82880 2014264
freeのところがだいぶあるのでメモリは余裕がありそうです。WordPressは重いですが。
スワップを調べる
スワップを調べるには色々コマンドがあるみたいなのですが、使用できたコマンドで調べました。
sar -uを使う
sar -u
というのを使うとスワップを調べられるようなので使用しました。
sar -u
略
17時40分15秒 CPU %user %nice %system %iowait %steal %idle
17時50分40秒 all 0.88 0.00 1.56 97.42 0.00 0.14
18時00分30秒 all 0.98 0.00 1.69 97.33 0.00 0.01
18時10分48秒 all 0.50 0.00 1.12 98.17 0.00 0.21
18時20分39秒 all 0.39 0.00 1.02 98.60 0.00 0.00
18時30分52秒 all 0.41 0.00 0.95 98.54 0.00 0.09
18時40分27秒 all 0.29 0.00 0.80 98.84 0.00 0.07
19時10分31秒 all 0.46 0.00 0.99 98.51 0.00 0.04
19時20分40秒 all 0.45 0.00 1.12 98.14 0.00 0.29
略
iowaitが98%になっています。でもそれは夕方頃の話で、23時のいまではありません。いまはiowaitは発生していないのです。
vmstatを使う
vmstat 30
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 82072 677000 8380 56332 3 2 4 3 1 0 0 0 100 0 0
0 0 82064 548100 8408 59268 5 0 103 3 136 54 3 0 96 1 0
0 0 82064 548172 8432 59272 0 0 0 5 40 16 0 0 100 0 0
0 0 82064 548048 8432 59272 0 0 0 1 36 14 0 0 100 0 0
あれswpdがあります。
消しかたがわからずrebootコマンドを試しました。
sudo reboot
Broadcast message from pugiemonn@pugiemonn.com
(/dev/pts/0) at 23:18 ...
sshから追い出されました。
もいちどsshしてvmstatを試しました。
vmstat 30
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 861172 10912 52668 0 0 405 15 132 123 1 1 91 7 0
0 0 0 861172 10920 52704 0 0 0 0 33 15 0 0 100 0 0
0 0 0 792808 12988 60688 0 0 334 3 164 93 2 0 94 4 0
swpdが消えました。でもWordPressが重いです。
サーバーは関係ない
どうやらスワップは多少発生していたもののWordPressの重さには関係ないようです。
サーバーは関係ないです。つまりサーバーが重いと考えていた最初の予想は外れていました。
フロントが重い?
次に、フロントが重いのかなと考えました。
そしてWordPressが吐き出すHTMLをみてみたらわかりました。
CSSの読み込み先が local.pugiemonn.com/hogehoge.css
のように、開発環境のCSSを見ようとしています。 local.pugiemonn.com
というホストはローカルのVagrant開発環境にしか存在せず、Vagrantをhaltしているのでアクセスできるはずがありません。アクセスできないCSSをずっと待っているので遅くなっているということがわかりました。
原因はWordPressのプラグインをGitで管理していたため
WordPressのとあるプラグインを使用していて、そのプラグインは管理画面からCSSのファイルを指定できるようになっていました。そして、管理画面で指定したCSSのフルパスをWordPress内にあるファイルに書き込むような仕様になっていました。このフルパスが相対パスじゃなくてホストから入るタイプのパスでした。ボクは勝手にローカルのDBに書き込まれると思い込んでいたのですが、ファイル書き込みという仕様であり、プラグインのファイルだから大丈夫だろうとよく確認せずGithubにあげる状態になってしまい、それを本番環境で利用したためにWordPressが重くなるという現象に遭遇したようです。
プラグインこわい(☝ ՞ਊ ՞)☝