原因不明と思っていた、当サーバのネットワーク不調ですが、意外とあっさり解決しました。原因は、ネットワークケーブルの劣化でした・・。お恥ずかしい限りで・・・。昨日ネットワークケーブルを新規に交換して無事解決しました。これで数年は大丈夫かな？と思います。ここを拝見して、参考になっているかなっていないかわからないけど、ご迷惑をおかけいたしました。

さてさて、すこしデータベースの話とかけ離れてしまいますが、データベースのパフォーマンスを維持する上でもっとも重要なハードウェアのファクターってなんでしょう？個人的には、

１にメモリ２にディスクの回転３にCPUだと思っています。

どのデータベースでも、おそらく同じだと思っていますが、いかがでしょうか？通常のデータベースのデータというのは、毎回毎回ディスクアクセスにいかないように、メモリ上にデータを展開し、オンメモリーでアクセスさせるようにすることでパフォーマンスを維持します。それの極端な例は、いわゆるインメモリデータベースってやつです。

たとえば、oracleですと、 Oracle TimesTen とか。 IBMですと、 solidDB とかがそれにあたりです。これらのデータベースは、参照に特化しているため（と自分でそう思っているだけかもしれませんが）トランザクション処理に向かないのが現状です。

通常のデータベースは、メモリに乗らない量のデータは、当然ながらディスクアクセスにいきます。なので、ディスクの回転が早ければ、レスポンスも良いと・・まあ当たり前ですね。じゃあ、ディスクのアクセスの状態でどこ見ればいいんでしょうか？というところで、いきなりデータベースから話が離れて、 linuxでは、iostatというコマンドがあります。

iostatは、ディスクの負荷状況を詳細にチェックするコマンドです。

iostat 5

なんて記述をすると、５秒毎に観測してくれます。ちょっと打ってみましょうか？こんな感じででてきます。

iostat 5

-bash: iostat: command not found あら？コマンドがないって怒られた。。。 yumでインストールします。sysstatというパッケージに格納されている模様なので、以下のようにして入手します。

yum -y install iostat

Loaded plugins: downloadonly, fastestmirror Determining fastest mirrors base: www.ftp.ne.jp updates: www.ftp.ne.jp addons: www.ftp.ne.jp extras: www.ftp.ne.jp base | 2.1 kB 00:00 primary.sqlite.bz2 | 2.0 MB 00:00 updates | 1.9 kB 00:00 primary.sqlite.bz2 | 251 kB 00:00 addons | 951 B 00:00 primary.xml.gz | 203 B 00:00 extras | 1.1 kB 00:00 primary.xml.gz | 116 kB 00:00 extras 289/289 Setting up Install Process Parsing package install arguments No package iostat available. Nothing to do ~]

yum install sysstat

Loaded plugins: downloadonly, fastestmirror Loading mirror speeds from cached hostfile base: www.ftp.ne.jp updates: www.ftp.ne.jp addons: www.ftp.ne.jp extras: www.ftp.ne.jp Setting up Install Process Parsing package install arguments Resolving Dependencies There are unfinished transactions remaining. You mightconsider running yum-complete-transaction first to finish them. --> Running transaction check ---> Package sysstat.x86_64 0:7.0.2-3.el5 set to be updated --> Finished Dependency Resolution

Dependencies Resolved

Package Arch Version Repository Size

Installing: sysstat x86_64 7.0.2-3.el5 base 173 k

Transaction Summary

Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s)

Total download size: 173 k Is this ok [y/N]: y Downloading Packages: sysstat-7.0.2-3.el5.x86_64.rpm | 173 kB 00:00 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : sysstat [1/1]

Installed: sysstat.x86_64 0:7.0.2-3.el5 Complete!

もう一度トライしたらこんな感じの結果になりました。

iostat -x

Linux 2.6.18-128.1.10.el5 (xxx.yyy.local) 2009年11月03日

avg-cpu: %user %nice %system %iowait %steal %idle 1.88 0.00 2.16 0.48 0.00 95.47

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.24 4.26 0.23 1.59 10.31 46.87 31.40 0.01 7.14 3.05 0.55 sda1 0.01 0.00 0.00 0.00 0.02 0.00 16.65 0.00 5.54 4.72 0.00 sda2 0.23 4.26 0.23 1.59 10.29 46.87 31.42 0.01 7.14 3.05 0.55 sdb 16.50 0.28 0.94 0.36 19.68 14.77 26.59 0.00 3.53 0.79 0.10 sdb1 3.29 0.05 0.06 0.08 3.37 1.01 31.31 0.00 3.98 1.54 0.02 sdb2 13.20 0.23 0.88 0.28 16.30 13.76 26.03 0.00 3.47 0.73 0.08 dm-0 0.00 0.00 0.45 5.86 10.27 46.87 9.05 0.07 10.68 0.88 0.55 dm-1 0.00 0.00 0.00 0.00 0.01 0.00 8.00 0.00 9.88 0.78 0.00

この見方ですが、以下のような感じになります。

基本的には-xオプションを付けて起動しましょう。リザルトの意味は以下の通りです。 http://wktm.jp/archives/901 さんから、お借りしました。そのまま掲載してすみません。

rrqm/s	マージされた読込ＩＯ要求（秒間）。ＯＳは可能な限り、複数のＩＯを一回のＩＯにまとめて性能の向上を図ります。この数値が大きいほど、効率よくディスクの性能を引き出せていることになります。
wrqm/s	マージされた書込ＩＯ要求（秒間）。ＯＳは可能な限り、複数のＩＯを一回のＩＯにまとめて性能の向上を図ります。この数値が大きいほど、効率よくディスクの性能を引き出せていることになります。
r/s	読込ＩＯ要求（秒間）。実際にディスクに発行された読み込み要求の回数です。この数値が大きいほど、多くの要求をこなしているということです。実運用においてはこの値は低く保つよう努力されるべきです。
w/s	書込ＩＯ要求（秒間）。実際にディスクに発行された書き込み要求の回数です。この数値が大きいほど、多くの要求をこなしているということです。実運用においてはこの値は低く保つよう努力されるべきです。
rsec/s	読み込まれたセクタ数（秒間）。ＩＯによって実際に読み込まれたデータのサイズであり、真のディスク性能指標と考えられる項目です。基本的には読込ＩＯ要求の値と連動しますが、大きなデータを扱う場合は読込ＩＯ要求の値以上に、良い性能を発揮できます。
wsec/s	書き込まれたセクタ数（秒間）。ＩＯによって実際に書き込まれたデータのサイズであり、真のディスク性能指標と考えられる項目です。基本的には書込ＩＯ要求の値と連動しますが、大きなデータを扱う場合は書込ＩＯ要求の値以上に、良い性能を発揮できます。
avgrq-sz	一つの要求の平均セクタサイズ。この値が大きいほど一度の要求で多くのデータを要求していることになります。この値が大きいシステムはソフトウェア的によく最適化されたシステムです。
avgqu-sz	ＩＯキューの長さの平均。未処理要求の溜まり具合を示します。この値が長時間高いままであるということは、要求を処理し切れていないということです。一時的に増減する分には問題有りません。
Await	要求を発行する平均時間間隔です。この値が小さくなるほど、頻繁にディスクに対して要求が発行されている事になります。
svctm	要求に対する平均レスポンスタイムです。この時間は短ければ短い方が良いと同時に、値が安定していることが非常に重要です。この値が大きく増減するシステムは高負荷に弱い証拠であり、データベース用途に向きません。