数日前にいただいた、こちらの記事へのコメント で、バックアップ処理でVPSに負荷をかけ過ぎているというご指摘があり、確かにホストサーバーへの負荷低減・ひいては自分のVPS環境を快適にする意味あいからも、処理を見直すべきかなということで、現在スクリプトを作成して動作テストを行っているわけですが、そもそも現在の負荷状況が分からなければ、改善したのか確認のしようがありません。
そして、さくらのVPS など一部のVPSサービスには、標準で負荷を確認できる機能があったりしますが、GMOクラウド VPS のコントロールパネルにはそのような機能が用意されていません(関係ないですが、リモートコンソールで相変わらず : とか一部の記号が入力できないって問題も直ってません。公表されてかなり時間経ってるのに……)。
ということで、自前でツールを用意しないとダメなので、簡単導入がウリの sar と munin を導入し、負荷状況を確認するための方法をまとめてみました。
余談ですが、いただいたコメント内の
安価に大量のリソースを調達しやすくなり、そして湯水のごとく使える環境に慣れ、
恵まれ過ぎて感覚が麻痺してしまっているのではないでしょうか。
というお言葉で、自覚はなかったけれども、確かに昔 K6 II 400MHz・512MBメモリ環境でSlackware使ってサーバー運営してた頃はリソースも厳しく、少しでも軽くするためにLinuxカーネル設定を突き詰めてコンパイルを繰り返したり(Slackwareを選んだのも最小構成で軽いという理由だったし)、いろいろと軽量化に腐心していたよなという思い出が甦ってきました。改めてコメントに御礼申し上げますと共に、作業へのモチベーションをいただき感謝いたします。
上段で熱かった頃の思い出を語っておいてなんですが、やっぱりパッケージ管理は便利だよねーと思うのは、こういう管理ツールもyum一発で入れられるときですな。いや、もちろんソースからコンパイルするのも楽しいし好きなんだけど、依存解決とかで詰まることもあるしね(そういやその辺りが面倒になってSlackwareやめたんだっけな……)。
# yum install sysstat
このコマンド一発で、CentOS 6.X環境なら入ると思います。
muninさんはepelレポジトリにあるので、これまでの設定記事で有効にしている、各種リポジトリも一緒に指定してインストールします。
# yum --enablerepo=remi,epel,rpmforge install munin
しかし、自分の環境では下記のようなエラーが出て失敗しました。
Transaction Check Error: file /usr/share/man/man3/XML::SAX::Base.3pm.gz conflicts between attempted installs of perl-XML-SAX-0.96-7.el6.noarch and perl-XML-SAX-Base-1.04-1.el6.rf.noarch file /usr/share/man/man3/XML::SAX::Exception.3pm.gz conflicts between attempted installs of perl-XML-SAX-0.96-7.el6.noarch and perl-XML-SAX-Base-1.04-1.el6.rf.noarch
そこで、こちらのサイト様の情報 を参考に、下記のように3回コマンドを実行します。
# yum install perl-XML-SAX-0.96-7.el6.noarch # yum update # yum --enablerepo=remi,epel,rpmforge install munin
自分の環境だと、2行目の yum update 実行時には何のパッケージもアップデートされなかったため、これは必要ないかもしれませんが、念のために。
さて、これで問題なくインストールまでは終わりましたが、各種設定ファイルを触らないとうまく動作しない場合もあるので、こちらのサイト様の情報 を参考に、その設定を行います。
本来ならば、上記サイト様の記事にある通り、最初に管理エリアにログインするためのIDとパスワードを設定しますが、自分の場合は固定IPからアクセスするため、その作業は行わず、設定ファイルの編集を行いました。
# vi /etc/httpd/conf.d/munin.conf
として、ファイル内の以下の行を
# AuthUserFile /etc/munin/munin-htpasswd # AuthName "Munin" # AuthType Basic # require valid-user
このようにコメントアウトし、代わりに
order deny,allow allow from 固定IPアドレス deny from all
のような行を追加します。あわせて、自分の環境だとセキュリティ上の理由で、バーチャルドメイン設定をしないと(IPアドレス直打ちだと) 403になるように設定を行っているので、バーチャルドメイン設定も追加します。このためだけにサブドメイン一つ設定するのはアレですが、別の用途のサブドメインを流用してもいいでしょう。
<VirtualHost *:80> ServerAdmin munin@example.com DocumentRoot /home/user/munin ServerName munin.example.com ErrorLog logs/munin.example.com-error_log CustomLog logs/munin.example.com-access_log combined env=!no_log </VirtualHost>
directory 設定も、上記にあわせて変更します。自分の場合は以下のようになりました。(元々のコメント行は省略しました)
<directory /home/user/munin> Options Includes FollowSymLinks ExecCGI MultiViews AllowOverride All order deny,allow allow from 固定IPアドレス deny from all # AuthUserFile /etc/munin/munin-htpasswd # AuthName "Munin" # AuthType Basic # require valid-user ExpiresActive On ExpiresDefault M310 </directory>
ここまで終わったら、設定ファイルを保存し、Muninが作成する管理ページデータからシンボリックリンクを張ります(下記は例です)。
# ln -s /var/www/html/munin /home/user/munin
後は、上記参考サイト様の情報通りhttpdを再起動し、munin-nodeを自動起動するように設定します。
# service httpd restart # service munin-node start # chkconfig munin-node on
上記3コマンドを実行したら、5分程度待ってから設定したバーチャルドメインのアドレスにアクセスします(以下は例です)。言うまでもないことですが、バーチャルドメインを新たに設定して利用する場合は、ネームサーバーの情報更新も忘れずに。
http://munin.example.com/
以前少し調べたり導入したりはしたものの、使いこなしているというレベルではないので、使い方についてはGoogle先生にお尋ねいただければと……。sarはともかく、muninについてはグラフィカルなツールなので、あまり迷うこともないかと思います。
ということで、早速muninでcron.dailyが動いたと思われる時間帯のDisk throughputのデータを保存してみました。さくらのVPS で規制対象になるという噂の、1MB/secには届いていませんが、書き込みに620KB/sec・読み込みに480KB/secくらいリソースを使っていることが分かります。
logwatchで発生する(主にリードと思われる) ディスクアクセスは仕方ないものとして、この状況がどのくらい改善するか、次回は新たに作成したバックアップスクリプトを、負荷データと共に紹介できればと思います。(3月初旬頃にはなんとか……)
View Comments
リソース消費量を適切に把握するのは大事な事ですよね。
そしてそれに応じて適切な対策を取らないといけない。
そのためにも具体的な負荷限度を各社ある程度の範囲で明示して貰いたいところだけど、難しいのかなぁ。
それが分かればどの程度の分散、対策が必要かも考えやすいのだけど。
ただ少なくともさくらとかみたいなリソースモニタはデフォルトで設けてほしいところ。
コメントいただきありがとうございます。
仰る通り、適切な情報把握は大切なことだと、今さらながら負荷監視ツールを
導入した次第です。(さくらのVPS使用時には導入していたのですが、移転した
際に入れ忘れてそのままでした)
リソースモニターについても、確かに各社でそれぞれの基準となる、リファレンス
としてのモニターを用意して欲しいですね。あわせて自分でもmunin等を導入し、
両方の値を比較したりすることで、より正しい負荷値を探ることができるかと思われ
ますし。(GMOクラウドVPSについては、その辺りを省いているので安くてコスパが
いいものと割り切ってはいますが)
さくらのVPS記事については、まさにその点を述べたかったのですが、私の文章力
のなさもあり、伝わりにくくなっておりまして申し訳ありません。突発的な一時の
負荷だけで(常時高い負荷を掛けているわけではないにもかかわらず) 制限がかかる
というのは不合理かなと感じたことがきっかけで、あのような内容となっており
ます。
各社の事情で制限がかかるのは当然ですし、それを避けるためには上位プランを
という話なら異論はないですし、(特に業務用途ならば) 多少高いお金を払うこと
に躊躇はありませんが、そもそもの制限値や制限のかけ方が分からなければ、上位
サービスに移転すれば安心とも言い切れず、難しいのかもしれませんけれども、
各社様にはどの程度の時間、どのくらいの負荷(CPU・Disk I/Oなど) を掛けたときに
このレベルまでの制限をかけますよ、と明記していただければありがたいですね。