vmstatのちょっとした謎

ベンチマークテストを実行して気づいたのだが、CentOSの(ということは、Red HatやFedoraでも?)vmstatコマンドのCPU値がちょっと謎。実際にコマンドを実行してみる。

[root@dc3 03]# vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  1  53644   9608    160 123704    0    0  4776  4988  227   35  1  8 34 56  1
1  1  53644   3060    116 142552    0    0    10 29670 5002 3292  0 43  0 54  2
0  2  53644   3488    104 142320    0    0     6 29871 6021 4053  2 40  0 56  2
[CTRL]+[C]
[root@dc3 03]#

CPU列には、us、sy、id、waおよびstの五つの値が表示されている。
それぞれどういう意味なのか、調べてみる。まずは日本語のman page。

CPU
これらは CPU の総時間に対するパーセンテージである。
us: カーネルコード以外の実行に使用した時間 (ユーザー時間、nice 時間を含む)。
sy: カーネルコードの実行に使用した時間 (システム時間)。
id: アイドル時間。Linux 2.5.41 以前では、IO 待ち時間を含んでいる。
wa: IO 待ち時間。Linux 2.5.41 以前では、0 と表示される。

なぜか、st値の説明がない。
では、英語版ではどうか。

CPU
These are percentages of total CPU time.
us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

つまり、stは仮想マシンに関係している。
CentOS 5.1では、kernelおよびkernel-xenは、2.6.18なので、id値にwa値が含まれない(つまり、wa値＞id値があり得る)。本当のアイドル時間とI/O待ち時間が分離されて表示される。

プライバシ・ポリシ

このサイトでは、Google Adsenseを使っています。

Google Adsenseによる広告が配信される過程で、このブログの管理者でもあなたでもない第三者が、あなたのブラウザ上のクッキーを認識し、読み取ったり、情報収集の目的でウェブビーコンを使用することがあります。

もし、第三者にあなたの行動を追跡されたくない場合には、あなたのブラウザの設定により、クッキーの読み取りを制限することができるはずです。

RHCS: iSCSI, DM-MP, CLVM and GFS・その9・考察

これまで、iSCSIを用いて二本の経路で共有されたブロックデバイスをCLVMで論理ボリュームとして扱い、その論理ボリュームをGFS2でフォーマットし、マウントする手順について述べた。この構成では、iSCSIターゲット=イニシエータ間のパスが複数存在するので、この間の接続が信頼性の急所(single point of failure)にならない。ここまでは、『その1・概要』および『その5・Device-Mapper Multipathの設定』で述べた通り。

ただし、今回の構成には、問題点がある。

• クラスタcDomUsのメンバ、dc[123]が仮想マシンフェンス(XVMフェンス)された場合、システム起動されても、iSCSIの接続は復旧しない。この場合、VGcDomUs00やLVGFS00は認識されず、GFS2ファイルシステムはマウントされない。
• iSCSIターゲット=イニシエータ間のパスが何らかの不具合で一時的に切断された場合、その後障害が復旧しても、当該パスは自動的に復旧しない。

iSCSIターゲット用RPMパッケージscsi-target-utilsの不具合によるものだ。この不具合は、『その4・iSCSIイニシエータの設定』で以下の通り述べた。

ターゲット側で使用するscsi-target-utilsで提供されるサービスtgtdは、同一パス・同一イニシエータ名でのセッションでの多重接続を拒否する。従って、イニシエータ側では、ユニークなイニシエータ名を使用する必要がある。
また、tgtdは、イニシエータが正常なログアウト処理を行わずに停止した場合、そのイニシエータに対するセッションを保持し続ける。このイニシエータが再起動され、ターゲットにログインしようとすると、ターゲット側には同一パス・同一イニシエータ名のセッションが残っているため、ターゲットはこのログインを拒否する。このため、このイニシエータはストレージにアクセスできなくなってしまう。

従って、少なくとも現時点では、CentOS 5をiSCSIターゲットとしたシステムでは、Device-Mapper Multipathの利点を活かしきれない。


『その1・概要』
『その2・インストールとクラスタの構成』
『その3・iSCSIターゲットの設定』
『その4・iSCSIイニシエータの設定』
『その5・Device-Mapper Multipathの設定』
『その6・CLVMの設定』
『その7・GFS2の設定』
『その8・Congaでの設定』
『その9・考察』