データムーバーによるLinux I / Oボトルネック

Ubuntuサーバー10.04を実行する94.6GiB RAMの24コアマシンがあります。同じタイプと同じ量のプロセスを実行している別のサーバー（4コア）とは異なり、ボックスでは高い％iowaitが発生しています。両方のマシンはVNX Raidファイルサーバーに接続され、24コアマシンは4つのFCカードを介して接続され、もう1つは2つのギガビットイーサネットカードを介して接続されます。4コアマシンは現在24コアマシンよりも優れており、CPU使用率が高く、％iowaitが低くなっています。

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つのマウントがある）にあると考えられますが、正確にはわかりません。何かアドバイス？

まず第一に、もしあなたのCPUが（そしていまいましい！24は多い）データがデータストレージを提供できるよりも速くデータを消費するなら、あなたはiowaitを得る。これは、ブロッキングIO（読み込みが遅すぎるか、同期書き込み）の間にカーネルがプロセスを一時停止するときです。
したがって、ストレージが24コアに十分なスループットを提供できることを確認してください。

たとえば、ストレージが500MB / sのスループットを提供でき、2ギガビットイーサネット回線（ボンド）を介して接続されていると仮定すると、ネットワークはすでに最大スループットを約100-180 MB / sに制限しています。プロセスが50 MB /秒の速度でデータを消費し、4コアマシンで4つのスレッドを実行する場合：4 x 50 MB /秒= 200 MB /秒の消費。ネットワークが180MB / sを維持できる場合は、レイテンシがあまりなく、CPUに負荷がかかります。ここのネットワークは小さなボトルネックです。
これを24コアと24スレッドにスケールアップする場合、1200 MB / sが必要になります。このようなスループットを可能にするように配線を変更しても、ストレージシステムは500 MB / sを超えないため、ボトルネックになります。

それがioの待機になると、ボトルネックはどこにでもある可能性があります。物理層だけでなく、ソフトウェアおよびカーネルスペースバッファにも。それは本当に使用パターンに依存します。ただし、ソフトウェアのボトルネックを特定することははるかに難しいため、通常、ソフトウェアスタックを調査する前に、ハードウェアの理論上のスループットを確認することをお勧めします。

前述のように、iowaitは、プロセスが読み取りを行い、データが到着するまでに時間がかかる場合、または同期書き込みを行い、データ変更の確認に時間がかかる場合に発生します。同期書き込みの間、プロセスは無停電スリープに入り、データが破損しないようにします。どの呼び出しがプロセスをハングさせるかを確認する便利なツールが1つありますlatencytop。これだけではありませんが、ぜひお試しください。

注：参考までに、dmはデータムーバーではなくデバイスマッパーを表します。

まず第一に、聖なる地獄はたくさんの鉄です！:)

残念ながらあなたの設定は非常に複雑に聞こえるので、誰もがすぐに「あなたの問題があります！」を提供できるとは思いません。答えは、非常に類似または同一の設定で何かをして同じ問題が発生した場合を除きます。したがって、このテキストはSUによって「回答」としてラベル付けされますが、おそらく「提案」のように考える必要があります。言葉が多すぎるのでコメントには入れません。：S

ハードウェアがデバイスにどのようにマップされているかを知らなければ、I / Oが別の場所ではなく、ある場所で行われている理由を説明するのは困難です。デバイスをどのようにマウントしますか？プログラムはsd*デバイスに直接アクセスしていますか、それともすべてのファイルシステムがdmデバイスにマウントされており、すべてのファイルアクセスはデバイスを通じて行われますか？

私が尋ねなければならない他のもの：

• それはどのようなRAIDですか？RAID5またはRAID6でパリティビットを計算している場合、それはraidサーバーハードウェアによって処理されると期待されます...そうでない場合、処理サーバーがそれを実行しています...これは最適ではなく、I / Oレイテンシを引き起こす可能性があります。ソフトウェアで行われます。

• 2つのサーバーの主な違いの1つをメッセージで分離しました。1つはファイバーチャネルを使用しており、もう1つはイーサネットを使用しています。ファイバーチャネルは、より良いレイテンシと帯域幅を提供する必要がありますが、それも問題である可能性があります。それが大量のスループットを提供している場合、RAIDサーバー自体が非常にビジーになる可能性があります...レイテンシが増加し、I / O待機が増加します。

まるで、ディスクアレイでバッファの膨張問題が発生する可能性があります。ハードウェアRAIDコントローラーには、通常、大量のオンボードキャッシュがあります。したがって、メディアへのI / Oがキューに入れられ、キャッシュがダーティページでいっぱいになると、最終的に全体が飽和し（機械的ストレージが負荷に対応できない場合）、レイテンシが屋根を通過します...確実に24コア+ FCの方が4コア+ GbEの場合よりも多くの負荷を生成できます:) RAIDサーバーをチェックして、ディスクのビジー状態を確認します...多くの「I / O」は制御パケットなどである可能性があります。 FCがどのように機能するかはわかりませんが、それがTCPのようなものである場合、待ち時間が長すぎると再送信が表示されます。

電話で誰かに質問しても、数秒間応答がない場合は、「こんにちは？」と言います。-ネットワーキングプロトコル（FCは単なるネットワーキングプロトコル）は同じことを、より短いタイムスケールで行います。もちろん、その余分な「こんにちは？」既に輻輳しているパイプにさらに多くのデータを追加するため、ネットワーキングのコンテキストではコストがかかります。

最後に、一般的なヒント：

レイテンシ/ IO待機/スループットの問題をデバッグするときは、常に測定します。どこでも測定。ネットワークで測定する、プログラム自体が実行していることを測定する、処理の終わりで測定する、RAIDサーバーで測定するなど。1つの視点からそれを単に見るだけではなく、パイプライン内のデータの処理、読み取り、書き込みを担当します。1つのトランザクションまたは1つの個別のワークユニットを分解し、ハードウェアを通る経路を正確に分析し、個別のコンポーネントごとに測定して、ボトルネックや過度のレイテンシがある場所などがないかどうかを確認します。 back the onion」、そして私はそれ以来、データフローをデバッグするタスクを指すためにこのフレーズを使用しています。

小さな追加。この場合、ブロックレベルのチューニングとI / Oスケジューラを確認することをお勧めします。私はUbuntuにはあまり詳しくありませんが、調整するストレージパフォーマンスのノブはたくさんあります。これは間違いなくSANストレージとデータベースの場合に当てはまります。

• 見てみましょうI / Oスケジューラシステムを。CFQがデフォルトですが、データベースワークロードの一般的な選択肢はnoopとdeadlineです。
• 役立つ可能性がある他のいくつかの調整パラメーターについては、このリンクを参照してください。
• あなたはNFSとブロックストレージに言及しています。ブロックされている場合、どのファイルシステムが使用されていますか？ここからは、I / O待機が書き込みブロッキング状態のように聞こえます。書き込みバリアは有効になっていますか？でファイルシステムを再マウントしますnobarrier。（Ubuntuのヒント）

いくつかの関連するサーバー障害リンク...

Linux-実際のハードウェアRAIDコントローラーのチューニング（SCSIおよびCCISS）

すべてのアイデアと入力に感謝します。この問題は、VNX自体の欠陥のあるI / Oモジュールと組み合わされた、最適でないイーサネットボンディング構成の組み合わせに関連していました。I / Oレートは、予想したところに近づいています。興味深いことに、ddファイルの書き込みと読み取りのテストとiozoneベンチマークではこれを検出できず、予想とほぼ同じ速度で読み取りと書き込みを行うことができました。

すぐに詳細を編集しますが、最初に、iostatのdm- *出力に混乱させないでください。デバイスマッパーは、md *（md0、md1など）と同様にカーネル内パススルーデバイスであるため、実際に使用しているのは基本となるデバイスのみです。ディスクに渡されるすべてのデータは途中でdm / mdを通過し、実際の合計（バイト、秒など）は正確ですが、utilは誤解を招きます。

また、これは非常に大量のメモリです。特に1つのプロセスがRAMの半分以上を占めている場合は、面白いことが起こり始めます（私自身も2x64sと2x96sを実行しています）。詳細については、この記事をお読みください。記事ではmysqlについて言及していますが、そうではないことに注意してくださいmysql固有。すべてのソフトウェアプロセスで、別の物理プロセッサのアクセスメモリにペナルティが発生します。48GBは1つのプロセッサに属し、48GBは別のプロセッサに属していると考えてください。プロセスは1つのprocにのみ属することができ、他のprocsメモリに到達するために（それ自体の48GBがなくなった後）、48の一部をスワップに保存するか、またはそこから取得するために莫大な価格を支払うかを決定する必要があります他のプロシージャのメモリ。この記事では、numactlコマンドを実行してソフトウェアを強制的にスワップせず、代わりにペナルティを支払うことを推奨しています。個人的にはこれによる大幅な改善が見られます。つまり、I / Oの一部がスワップするかどうかを確認してください。これには、free -m（または類似の）を使用します。十分な空きメモリがあっても、かなりの量のスワップページ（たとえば10％プラス）がある場合は、これが問題になる可能性があります。

これをストレージの観点から見て、SCSIレイテンシを測定する方法はありますか？OS ioの待機時間には、ストレージの制御外にある多くのものが含まれますが、ストレージボックスに移動して2msでIOレイテンシを確認すると、サーバーが内部で取得しているものに関係なく、scsiコマンドが応答されていることがわかりますすばやく、ストレージを変数として排除できます。