VPSサーバチューニング 2ヶ月目

2月のチューニングは試行錯誤の一ヶ月でした。メモリ1GBって微妙に足りない。

高負荷時のhttpレスポンスが極端に落ちる問題を解決

20150302_httping_resp_riscascape_net-month
まず始めにmuninのレスポンス計測はhttpingを止めてcurl一本にしました。で、先月のhttpレスポンスの結果がコレ。clamavのスキャンが走るとswapが発生し、一時的にhttpレスポンスが極端に落ちます。酷い時は6.8秒という時もありました。httpdとclamdのパラメータを試行錯誤した結果、メモリ消費を抑える方向で調整したところ改善に向かっています。

具体的にはhttpdのMaxSpareServersの調整とMaxRequestsPerChildの値を絞ってメモリ開放を早めに行うこと。構築当初httpdは1スレッドあたり約35MBほどメモリを消費する計算でいましたが、WordPressはメモリ消費が大きく200リクエスト処理で約90MBのメモリを消費します。

20150302_memory-month
2月の始めごろはprefork.cのServersの値を全て15固定にしていたため、最大900MBほどのメモリを消費し物理メモリのほとんどを圧迫している状態になっていました。この状態でさらにclamdのスキャンが走ればswapが発生するのは当然です。

/etc/httpd/conf/httpd.conf
<ifmodule prefork.c>
StartServers      10
MinSpareServers   10
MaxSpareServers   10
ServerLimit       10
MaxClients        10
MaxRequestsPerChild  100
MaxMemFree 1024
</ifmodule>

ということでMaxRequestsPerChild=100にしたところメモリ消費は1スレッド約70MBに減り、各Serversを10に固定で理論上の消費メモリも最大700MBに抑えられ、clamdのスキャンが発生してもメモリコミットが1GBを切りswap発生を抑えられるようになりました。

次にclamdのスキャンに利用する最大スレッド数をデフォルトの50から20に下げてみます。変更後もスキャン時間は特に変わらずにスキャン中のhttpdのレスポンスタイムが改善されたので、メモリ量とスレッド数のバランスが改善されたと考えられます。

/etc/clamd.conf

- MaxThreads 50
+ MaxThreads 20

jetpackを止めて低負荷時のレスポンスタイムを改善

httpレスポンスを見ると2015年09週からstarttransefer timeが110ms以下に改善されているのがわかります。ちょうどWordPressのjetpackプラグインをアンインストールした時期なので、これが原因のはずです。

もともとjetpackはWordPress→FaceBookの自動記事投稿のためだけに導入したものです。せっかく重いプラグインを入れているのだからと他の機能も試しましたが、どれも私のサイトではイマイチ。結局自動投稿はRSS+IFTTTに任せ、jetpackはアンインストールしました。その結果、サイトは軽くなり、phpとphp-eAcceleratorのメモリ消費量を減らすことが出来て一石二鳥になりました。