私は94.6GiB RAM Ubuntuサーバー10.04を実行している24コアマシンを持っています。同じタイプと量のプロセスを実行している別のサーバー(4コア)とは異なり、ボックスは高い%iowaitを経験しています。両方のマシンはVNXRaidファイルサーバーに接続されています。24コアマシンは4つのFCカードを介して接続され、もう1つは2ギガビットイーサネットカードを介して接続されています。 。
9日間の稼働時間では、%iowaitの平均は16%であり、通常は30%を超えています。ほとんどの場合、CPU使用率は非常に低く、約5%です(iowaitが高いため)。十分な空きメモリがあります。
私が理解していないことの1つは、すべてのデータがデータムーバーを直接通過するのではなく、デバイスsdcを通過しているように見える理由です。
avg-cpu: %user %Nice %system %iowait %steal %idle
6.11 0.39 0.75 16.01 0.00 76.74
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 1232 0
sdb 0.00 0.00 0.00 2960 0
sdc 1.53 43.71 44.54 36726612 37425026
dm-0 0.43 27.69 0.32 23269498 268696
dm-1 1.00 1.86 7.74 1566234 6500432
dm-2 0.96 1.72 5.97 1442482 5014376
dm-3 0.49 9.57 0.18 8040490 153272
dm-4 0.00 0.00 0.00 1794 24
dm-5 0.00 0.00 0.00 296 0
パズルのもう1つのピースは、タスクが頻繁に中断できないスリープモード(上部)に入るということです。これもおそらくioのホールドアップが原因です。
問題の診断に役立てるために何を見ることができますか?すべてのデータが/ dev/sdcを通過するのはなぜですか?それは正常ですか?
更新:
ネットワーク接続とVNXの読み取り/書き込み容量は、ボトルネックとして除外されています。 4つのボンディングされたNIC(ラウンドロビン)を使用すると、800MB /秒の速度に到達できます。ファイバチャネルカードはまだ使用されていません。 VNXは、IO(RAID6、2つのプールのプールあたり30x2TB 7.2kRPMディスク(合計60ディスク)、約60%の読み取り)を適切に処理できます。
上記のdmとsdcについては無視してください。これらはすべて内部ディスクであり、問題の一部ではありません。
問題はnfsマウントまたはTCP(VNXの5つのパーティションに5つのマウントがあります))にあると思われますが、正確にはわかりません。アドバイスはありますか?
アイデアとインプットをありがとうございました。この問題は、最適ではないイーサネットボンディング構成と、VNX自体の欠陥のあるI/Oモジュールの組み合わせに関連していました。 I/Oレートは、予想どおりに近づいています。 ddファイルの書き込みと読み取りのテストとiozoneベンチマークではこれを検出できず、期待どおりの速度で読み取りと書き込みができたことは興味深いことです。
まず第一に、CPU(そしてくそー!それは24です)がデータストレージを提供できるものよりも速くデータを食べる場合、あなたはiowaitを取得します。これは、カーネルがブロックIO(読み取りが遅すぎる、または同期書き込み)中にプロセスを一時停止するときです。
したがって、ストレージが24コアに十分なスループットを提供できることを確認してください。
たとえば、ストレージが500MB /秒のスループットを提供できると仮定します。2ギガビットイーサネット回線(ボンド)を介して接続されている場合、ネットワークはすでに最大スループットを約100〜180MB /秒に制限しています。プロセスが50MB/sの速度でデータを消費し、4コアマシンで4つのスレッドを実行する場合:4 x 50 MB/s = 200 MB/sが消費されます。ネットワークが180MB /秒を維持できる場合、待ち時間はそれほど長くなく、CPUがロードされます。ここのネットワークは小さなボトルネックです。
これを24コアと24スレッドにスケールアップすると、1200 MB/sが必要になります。このようなスループットを可能にするために配線を変更しても、ストレージシステムは500 MB/sを超えません。それがボトルネックになります。
Io waitになると、ボトルネックはどこにでもある可能性があります。物理層だけでなく、ソフトウェアおよびカーネルスペースバッファでも。それは本当に使用パターンに依存します。ただし、ソフトウェアのボトルネックを特定するのははるかに難しいため、通常は、ソフトウェアスタックを調査する前に、ハードウェアの理論上のスループットを確認することをお勧めします。
前述のように、iowaitは、プロセスが読み取りを行ってデータが到着するまでに時間がかかる場合、またはプロセスが同期書き込みを行ってデータ変更の確認応答に時間がかかる場合に発生します。同期書き込み中、データが破損しないように、プロセスは無停電スリープに入ります。どの呼び出しがプロセスをハングさせるかを確認するための便利なツールが1つあります:latencytop
。それだけではありませんが、試してみることができます。
注:参考までに、dmはデータムーバーではなくデバイスマッパーを表します。
まず第一に、鉄分が多い聖なる地獄! :)
残念ながら、セットアップは非常に複雑に聞こえるので、誰もすぐに「問題があります!」を提供できるとは思いません。彼らが非常に類似または同一のセットアップで何かをし、同じ問題に遭遇した場合を除いて、答えてください。したがって、このテキストはSUによって「回答」としてラベル付けされていますが、おそらく「提案」のように考える必要があります。言葉が多すぎるのでコメントには入れません。 :S
ハードウェアがデバイスにどのようにマッピングされているかを知らなければ、I/Oが別の場所ではなくある場所で行われる理由を説明するのは困難です。デバイスはどのようにマウントされていますか?プログラムはsd*
デバイスに直接アクセスしていますか、それともすべてのファイルシステムがdm
デバイスにマウントされており、すべてのファイルアクセスはそこから行われますか?
私が尋ねなければならない他のこと:
どんなRAIDですか? RAID5またはRAID6でパリティビットを計算している場合、それはRAIDサーバーハードウェアによって処理されることが期待されます...そうでない場合、処理サーバーはそれを実行します...これは最適ではなく、I/O遅延を引き起こす可能性があります。ソフトウェアで行われます。
メッセージ内の2つのサーバー間の主な違いの1つを分離しました。 1つはファイバーチャネルを使用しており、もう1つはイーサネットを使用しています。ファイバーチャネルshouldより良いレイテンシーと帯域幅を提供しますが、それも問題かもしれません。それが多くのスループットを提供している場合、それはRAIDサーバー自体を非常にビジーにする可能性があります...そして輻輳はバッファ/キャッシュがいっぱいになると、レイテンシが増加し、I/O待機が長くなります。
それはまるであなたがmayディスクアレイにバッファ膨張の問題を抱えているかのようです-あなたは知っていますか?ハードウェアRAIDコントローラーには通常、大量のオンボードキャッシュがありますね。したがって、メディアへのI/Oがキューに入れられ、キャッシュがダーティページでいっぱいになると、最終的には全体が飽和状態になり(機械的なストレージが負荷に追いつかない場合)、レイテンシーが屋根を通り抜けます...確かに4コア+ GbEよりも24コア+ FCの方が、より多くの負荷を生成できます:) RAIDサーバーをチェックして、ディスクのビジー状態を確認してください...多くの「I/O」は制御パケットなどである可能性があります。 FCがどのように機能するかはわかりませんが、TCPのようなものであれば、遅延が高すぎると再送信が発生します。
電話で誰かに質問しても、数秒間応答しない場合のように、「こんにちは?」と言います。 -ネットワークプロトコル(およびFCは単なるネットワークプロトコルです)は、同じことを、より短いタイムスケールで実行します。しかしもちろん、その余分な「こんにちは?」すでに混雑しているパイプにさらに多くのデータを追加するため、ネットワーキングのコンテキストではコストがかかります。
最後に、一般的なヒント:
レイテンシー/ IO待機/スループットの問題をデバッグするときは、常に測定。どこでも測定します。有線で測定し、プログラム自体が実行していることを測定し、処理側で測定し、RAIDサーバーで測定します。1つの観点からそれを見るだけでなく、システムの個々のコンポーネントを検討してみてください。パイプライン内のデータの処理、読み取り、または書き込みを担当します。 1つのトランザクションまたは1つの個別のワークユニットを分解し、ハードウェアを通過するパスを正確に分析し、各コンポーネントで測定して、ボトルネックや過度の遅延がある場所などがあるかどうかを確認します。私の友人はこれを「剥離」と呼びました。それ以来、データフローをデバッグするタスクを指すためにこのフレーズを使用してきました。
小さな追加。この場合、ブロックレベルのチューニングとI/Oスケジューラを確認することをお勧めします。私はUbuntuにあまり詳しくありませんが、Tweakにはかなりの量のストレージパフォーマンスノブがあります。これは、SANストレージとデータベースの場合に間違いなく当てはまります。
nobarrier
を使用してファイルシステムを再マウントします。 ( buntuのヒント )いくつかの関連するサーバー障害リンク...
すぐに詳細を編集しますが、最初に、iostatのdm- *出力で混乱させてはいけないことをお伝えしたいと思います。 Device-mapperは、md *(md0、md1など)と同じようにカーネル内のパススルーデバイスであるため、実際には基盤となるデバイスのみを気にします。ディスクに渡されるすべてのデータは途中でdm/mdを通過し、実際の合計(バイト、秒など)は正確ですが、utilは誤解を招く可能性があります。
また、それは非常に大量のメモリです。特に、RAMの半分以上を占めるプロセスが1つある場合は、その高さで面白いことが起こり始めます(私自身は2x64と2x96を実行しています)。 詳細についてはこの記事をお読みください 。この記事ではmysqlについて言及していますが、ではなくmysql固有であることに注意してください。すべてのソフトウェアプロセスには、別の物理プロセッサのアクセスメモリに対してペナルティが発生します。48GBは1つのプロセスに属し、48は別のプロセスに属していると考えてください。プロセスは1つのprocにのみ属することができ、他のprocメモリに到達するために(それ自体の48GBがなくなった後)、48の一部をスワップに格納するか、または他のprocのメモリ。この記事では、numactlコマンドを実行して、ソフトウェアを強制的にスワップせず、代わりにペナルティを支払うことを提案しています。私は個人的にこれから大幅な改善を見てきました。言い換えると、I/Oの一部がスワップするかどうかを確認してください。これにはfree-m(または同様のもの)を使用します。十分な空きメモリがあるが、重要な量のスワップページ(たとえば、10%以上)がある場合、これが問題になる可能性があります。
これをストレージの観点から見ると、SCSIレイテンシを測定する方法はありますか? OS ioの待機時間には、ストレージの制御外の多くのものが含まれますが、ストレージボックスに移動して、2ミリ秒でIOレイテンシーを確認すると、サーバーが何を取得しているかに関係なく、内部的には、scsiコマンドは迅速に応答されており、変数としてのストレージを排除できます。