前回はこのWebサイトを構築しているサーバでメモリリークが発生していることがわかりました。
今回はその原因を調査してみたいと思います。
Webでの調査
「OpenVZ」「dcachesize」で検索すると英語でいろいろ情報がでてきます。
- Troubleshooting OpenVZ Out of Memory and Could Not Allocate Memory Errors
私と同じくdcachesizeが大きくなりすぎてメモリ不足が発生している。
この人はvzctlコマンドでdcachesizeの上限を増やして解決している。 - dcachesize keeps increasing
dcachesizeが増え続ける現象が発生。解決方法はなし？ Bug 2143(リンク切れ) – Kernel cache memory leak
開発者らしき人が何が問題なんだと逆切れ(?)している。
「echo 3 > /proc/sys/vm/drop_caches」を実行するとキャッシュをフラッシュ(破棄)するので、dcachesizeは小さくなるが、ディスクアクセスのパフォーマンスは低下するらしい。
どうも困っている人は私以外にもいるようですが、根本的な解決策は見つけることはできませんでした。上記で示されているvzctlによる上限アップや、drop_cachesを使った強制破棄はServersMan@VPSでは残念ながら許されておらず、用いることができません。
dcachesizeが増える要因は？
Webに情報がないとなると自分で考えるしかありません。
dcachesizeは「dentry(ディレクトリ情報)」「inode(ファイル情報)」のキャッシュとのことなので、ファイルの頻繁な作成・削除が問題なのではないかと、推測しました。
私のサイト(Nginx+WordPress)でファイルの作成・削除が激しい処理は何かと考えたところ・・・
- Nginxのプロキシ・キャッシュ
- WordPressのWP Super Cacheプラグイン
の二つが思いつきました。
dcachesizeの増減の計測
NginxのプロキシキャッシュとWordPressのWP Super CacheプラグインのON/OFFした状態で、dcachesizeの増加具合がどうなるか測定してみました。
測定開始からの経過時間を横軸に、dcachesizeの値を縦軸にとったグラフが下記になります。凡例の「PC」はNginxのプロキシキャッシュ機能を、「WSC」はWordPressのWP Super Cacheプラグインを意味しています。
各グラフとも「増減を繰り返す期間」「単調に増加する期間」「大幅に減るタイミング」があることがわかります。
測定開始時刻がばらばらだったため上記のグラフではわかりませんが、実は「増減を繰り返す期間」はいずれも午前2時半から午前5時半で3パターンとも共通していることがわかりました。
そこで横軸を時刻に変更し、午前3時からグラフを作成してみました。なお、青のパターンは午前6時から測定を開始したため、翌日午前3時からのデータを使っています。
このグラフから次のことがわかります。
- 3つのグラフとも6時過ぎからほぼ単調増加傾向で増え続ける (メモリリークは解消していない)
- 一番増加が早いのはプロキシ・キャッシュとWP Super Cacheプラグインの両方がONの場合
すなわち、プロキシ・キャッシュやWP Super CacheをONにするとdcachesizeの増加が早くなる
2番目のことからプロキシ・キャッシュとWP Super Cacheがdcachesizeの増加に寄与していることは確かなのですが、OFFにしても結局はdcachesizeの上限を超えてしまうことから意味がありません。
他のアプローチを取ったほうがよさそうです。
プロキシ・キャッシュの削除期間を短縮
設定ファイルを見直していて、Nginxでのプロキシ・キャッシュの設定がキャッシュ・ファイルを24時間保持するようになっていたのに気づきました。
キャッシュ・ファイル自体は有効期限を1時間にしているので24時間保持しても仕方がありません。無駄なファイルがディスクに残っていてそれがdcacheを消費しているのかもしれません。
そこでキャッシュファイルの有効期限を2時間にして再びdcachesizeを測定してみました。
このグラフでも横軸は時刻としています。Nginxのプロキシキャッシュのキャッシュファイルを2時間で削除するとdcachesizeの増加はやや緩やかになりますが、やはりdcachesizeは増え続けるのでこの対策は有効とはいえません。
dcachesizeが増減を繰り返す期間を調査
次に注目したのはdcachesizeが増減を繰り返す期間があることです。
dcachesizeを計測していると、午前2時半から午前5時半あたりは増減を繰り返しdcachesizeが増加しないということで共通しています。
この期間は実はWordPressのBackWPupプラグインでメンテナンス・バックアップ関係の処理が毎日スケジュールされています。
dcachesizeの測定結果とBackWPupプラグインのスケジュールを付き合わせると、ジョブが動いた直後にdcachesizeが減っており因果関係が認められました。
ただ、スケジュールされているジョブは「データベースのチェック」「データベースの最適化」「データベースのバックアップ」「アップロードしたファイルのバックアップ」「プラグインのバックアップ」「テーマのバックアップ」・・・と統一性がありません。
いずれのジョブが動いた動いたあとにも多少の差があるもののdcachesizeは減っています。
ただ、データベース関連のジョブが走るとdcachesizeが大きく減少する傾向があるような気がします。特に「データベースのチェック」がdcachesizeに大きく影響を与えるようです。
まとめ
今回はdcachesizeの増加傾向を測定して増加の原因を調査しました。
Nginxのプロキシ・キャッシュやWordPressのWP Super Cacheプラグインを疑ってみましたが、dcachesizeに影響していることはわかったものの、増加を続ける原因ではないようでした。
一方、BackWPupプラグインでスケジュールしているジョブが走る期間はdcachesizeの増加が抑えられることもわかりました。
次回はBackWPupプラグインを使ってdcachesizeの増加問題の対策を検討したいと思います。
コメント