専用サーバーでサイトを運営しています。

一般的に b の値が高いのは、I/O待ちをしているプロセスがたくさんあるということを意味します。

bi/bo の値も確認してください。これらも大きいと、ハードディスクの読み書きが頻発している状態にあります。

原因として考えられることは

• メモリ不足
• ディスクに異常がある
• 他のデーモンなどが頻繁にディスクアクセスしている

などです。

こちらですが、mysqlの書き込みor読み書きだと思うんですよね。

mysqlのプロセルをkillすると「b」の値が急激に下がります。

この「b」を一定の値で制御できないんですかねー

ディスクのI/O 待ちを制御するって事は、MySQL が受け付けるコネクションの量を減らして

処理自体を減らすしかないと思うが。

MySQL プロセスのみが原因でメモリに余裕があるなら key_buffer 等を多めにとれば

アクセス頻度を下げることは出来るかもしれない。

いずれにせよパフォーマンスチューニングの領域だとは思う。

DBMSに対するアクセスに対してデッドロックを起こしているのではないでしょうか。それによって資源が枯渇している可能性が高いと思います。

#1のコメントに対して：

limits.confを書き換えることで、利用できるリソースを制限することはできますが、まずは#2さんの回答通り、MySQL のチューニングを試みるべきでしょう。

そもそも MySQL のみでそれだけのディスクI/Oを要求しているならば、それだけの処理をしているということなので、それを制限してしまうと、正常にトランザクション処理できなくなります。

ただし、以前のサーバと比較して、メモリ容量が極端に小さいようでしたらメモリの増設をお勧めします。

回答回数上限になりましたので、これにて失礼します。

回答回数上限設定を変更していただいたので、#4のコメントに回答します。

ご利用のOSも分かりませんし、MySQLにどのような処理を行わせているのか分からないので何とも言えませんが、まず、下記サイトを参考に、どのくらいのメモリ量が必要なのか計算してください。

• MySQL メモリ使用量の計算式

これらのパラメータの変更が可能なら、まず、チューニングを試みてください。

チューニングができないようなら、メモリを増設してください。32bit Linux であれば、MySQL は4Gバイトまで対応します。

VPSの２ＧはVPS利用者間で２Ｇを共有しているんですよね？

そうですが、同時にメモリ空間を使い切ってしまうことはないと思うので、各々のユーザーに2Gバイトを割り当てているのではないでしょうか。

ただし、VPSと現在の専用サーバのOSが違うとすると、一概に比較することはできません。同じLinuxでもディストリビューションや走っているデーモンが異なれば、利用可能なメモリ量は変わってきます。

厳密な状況を見ていないので本当に MySQL だけが原因かわかりませんが、一応チューニングのポイントを。

原則 id:pahoo さんのおっしゃるとおり

そもそも MySQL のみでそれだけのディスクI/Oを要求しているならば、それだけの処理をしているということなので、それを制限してしまうと、正常にトランザクション処理できなくなります。

という状況が予測されるので、自分の回答の以下の部分は最後の手段といった感じです。

コネクションを減らすということは

行列に並ぶもの自体を減らすということですよね。

行列自体の長さを制限するわけですから、それ以上の人が集まればエラーになりますので。

MySQL でチューニングできるパラメーターは多くありますが、それだけで何倍にも性能アップするケースは

まれなので原則 SQL の見直しやアプリケーション側の処理方法変更のほうが効率的です。

DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！

どこがネックになっているかを調べるには slow-query ログを設定するのがたいていの場合即効性がある。

【MySQLウォッチ】第8回 MySQLチューニングのテクニック：ITpro

ここに出てくるクエリだけでも書き換えるとスループットは改善する可能性が高い。

負荷が高い状況に直面できれば mytop/innotop といったツールで直接的に状況を見ることも出来ます。