「さくらのVPS」のディスク負荷が早朝4～6時に高い件。iowaitが酷いレベルに
ウチの例だけを取り上げて「さくらのVPS」が全部こんな有り様、と言いたいわけではなく、収容されているホストがたまたま、という話とは思いたいのですが。
使っている「さくらのVPS 2G」が、早朝になるとヒーヒー言って酷い有り様になっている件について、一応、同じ境遇の人もいるかもしれないので、ちょこちょこと書いておきます。
なんというか、そろそろ「さくらのクラウド」とかSSDプランに移行した方が良い頃合いのような気も…。
ひと言で「サーバの負荷」と言ってもいろんな種類の負荷があるわけですが、今回は、iowait / Disk latency / IO Service time といったあたりの性能劣化で困っちゃう。というケース。端的に言えば「ディスクが遅い」という事です。
別段I/Oインテンシブなサービスを動かしているわけでもないのですが、毎朝、決まって4時～6時ごろになるとI/O性能がかなり悪化し、酷いと、早朝3時頃から昼の12時前後まで微妙にその状況が続く事もありました。
僕自身、「自サーバに割り当てられたリソースが刻々と変わる共有サーバ」には若干不慣れなこともあり、自信を持ってこの記事を書けるようになるまでにそれなりの紆余曲折はあったわけですが、結論から言うと、同居している他の仮想サーバの早朝 cron（スケジュールされたバッチ処理）のあおりを受け、IO 性能が悪化している。と確信を持つに至りました。
ディスク書き込みが1年で1桁悪化
で、具体的にどのくらい性能が悪化しているのか。ですが…
munin の平均レイテンシ年間グラフを見ると、1年前に比べ、Write IO Wait time がおよそ1桁も遅くなっています。
IO Service time もこの有り様。
ちなみに、ウチのVPSの年間I/Oはこんな感じ。
年の途中でトラフィックを一部別ネットワークへ分散させた事もあり、ウチの IO write はむしろ減っている状況です。
同居している他の仮想サーバが以前より良く使われるようになってきた。という事なのでしょうか。
で、この画像を貼るのか…は、迷うところではありますが思い切って貼ってしまうと、ディスクのレイテンシが時間帯によって1秒を超えてますがな…（悪寒）
参考までに、同一区間のディスクIOはこんな感じ。大した負荷はかけていないと思うんですが。
なのに、IO service time が1秒を超える時もあったり。
今はたまたま、このVPSの負荷をかなり軽くしていた事もあって、WEB（Wordpress）の動作に問題はあまり出ていませんが、今後もこの調子でレスポンスが悪化すると、近いうちに破綻しそうな気がします。
早朝のcronが集中する時間はディスク周りがかなり遅く
今回の件については、ある程度確信が持てた段階で「さくら」のサポートに問い合わせをしており、昨日その回答が来たのですが、やはり、早朝4～6時は cron が集中するからディスク性能が落ちるよ。との回答でした。
こちらからも具体的な数値を挙げて問い合わせしましたが、それでも異常との回答ではなかったので、こういう事はありうる。という認識でいた方が良いだろうと思います。
どのプロセスのI/O負荷が高いのか、現場をおさえる
さて、さくらさんから「まぁ、こういうものですよ」という趣旨のご回答を頂戴してしまい、でもまぁ、この値段であのハード構成なら、運が悪いとそういう事もあるのかもね。と思わなくもなかったので、今の枠の中でどうにかする方法はあるのか、少しだけ検討しました。
（もっとも、最終的には別のサービスなり、上のプランに乗り換える予定ですが…）
現状、IO負荷が極端に高い時に（普段はスワップしないのですが）運悪くスワップすると、サーバーが落ちてしまう（このあたりの挙動も興味深いところで、書き始めたらキリがありません）という事も起こってるんですよね。
どちらにしても専用サーバーでない場合の I/O はボトルネックになりやすいか、あるいはコスト要因になりやすいかのどちらかであることが想定できたので、いい機会と思い、ウチのVPSで当該時間に一番ディスクI/Oに負荷をかけている WEB / DB 以外のプロセスはどれなのか、を、押さえておくことにしました。
munin やら sar を使えば、症状発生時の状況を後からでも追えますが、プロセス単位の詳細についてはそれだけでは追えない値もあるため、今回はターミナルを2つ開き、それぞれで以下のコマンドを実行してみました。
# pidstat –d 1
# sar –d 1
で、「sar –d 1」の await 値が大くなった時に I/O を利用していたプロセスを「pidstat –d 1」で見てみます。（もっと良い方法はあるかもですが）
その結果、監視サービスの munin が動くとディスク待ち時間が増える事と、早朝4時台には sar の await 値が 4桁に届くことがある事が分かりました。
munin の IO 負荷の高さはよく知られる所で、最初に直感で疑ったのも munin だったのですが、監視対象が一台しかないのに負荷対策しないといけないとかありえんだろ。と思ってスルーしてたんですよね。
とりあえずは、rrdcached などの導入なり、グラフ生成コストを下げる設定なり、別のソリューションを検討するなりで、どうなるのかを見つつ、システム全体としてはIO性能がもう少し安定して出せそうな契約・サービスに移行したいとは思っています。
あと、一応、ここに書いてある事とは別で、ファイルシステムのマウントに noatime の設定を入れたらいいんじゃないか、とか、MySQL のテーブル Analyze / Optimize や、Wordpress の不要リビジョン削除。Wordpress の WP-Cron の設定を覗いて、W3TotalCache の Preload 設定がちゃんと切れていないのでは？とかとかも疑いましたが、これらは「シロ」との判定でした。
とはいえ、使い方によってはお値打ちな「さくらのVPS」
幾分しょっぱい話をした「さくらのVPS」ですが、ピーク性能に関して言えば下馬評通りで、お値段の割にかなりのオトク感がある。とは今でも思っています。
が、今回のように、他の仮想サーバの IO の影響を受ける時間帯がありうる。という事は知っておいた方が良さそうです。
国内向けWEBトラフィックのピークタイムをうまく避けて症状が出るため、用途によってはこれで十分。というケースも多そうですが、負荷が早朝にも及ぶケースがあるようなので、業務用途なんかでは、より性能の高い「さくらの VPS SSD」を使うなど、考えたほうが良い気がしなくもありません。
また、これは正しいか分かりませんが、なんとなーく、他の仮想サーバの負荷が高くても一定のIO性能を確保したい。という用途には、そもそもVPSが向いていない。という話にもなりそうな予感はしなくもありません。（VPSサービスにもよるかもですが）
関連情報：
さくらのVPSの制限は2時間解けない | Nacky – Snowland.net says:
7年前
[…] ■「さくらのVPS」のディスク負荷が早朝4～6時に高い件。iowaitが酷いレベルに | TeraDas－テラダス […]