ここには複数の質問がありますが、それはこれから始まります。RAID10構成のPERC 6/i RAIDコントローラ(または複数のコントローラ)を備えたDell PowerEdgeR710があります。
システムはUbuntuServer 10.04 LTSを実行しており、MySQLは読み取り集約型のワークロードを実行しています。
blockdev --setra ### /dev/sda
を使用して先読みを増やし、先読みを増やしました(少なくとも理論的には、読み取りは順次読み取りです)。これは大きな影響を与えていないようです。ディスクエレベータを変更していません(noop
とdeadline
をお勧めします)。
システムの負荷が急上昇し、ディスクI/Oの待機に関連しているようです。システムは、ディスクI/Oを最大50%の時間待機することができますが、CPU%は約7〜10%です。 RAID5と書き込み集約型のMySQLインストールを備えた同等のシステムは、このシステムを完全にスモークします。
Dell OpenManageの報告によると、RAID10システムには2つのPERC 6/iコントローラがあるようです。ただし、コントローラー0のみにエンクロージャーがあり、コントローラー0のみにRAIDがあります。 RAIDは、2つの空きスロットを持つ4つのディスク(スロット0〜3だと思います)で構成されています。
システムは、オペレーティングシステムがCPU速度を管理できるようにするPowerSavingプロファイルでも実行されています。
システムはまた一部のLinuxカーネルで見つかったfsync()バグに悩まされています。
最後に、PERC 6/iは、ファームウェアが古くなっていることを報告しています。ファームウェアは6.2.0-0013であり、6.3.0-0001が必要です。
今の質問:
ディスクを恐ろしいほど高速にザッピングするような構成があるのではないかと強く思いますが、それを特定することはできないようです。
更新:ここで使用されている4つのディスクは、Hitachi HDS721010CLA332モデルです。これは、SATA「バスプロトコル」を備えているが、「SASアドレス」も備えていると記載されていますか?これらのディスクは、私が聞いたSASになりすましているドライブで、かなり遅いと思われますか?いずれにせよ、これらは明らかに7200RPMドライブです。
比較システムには、SASドライブ:Seagate ST31000640SS-7200 RPMが含まれています。この比較システムには、RAIDコントローラーが使用され、「バックプレーン」エントリが関連付けられています。
PERC 6/iはデュアルポートコントローラーです。各ポートには4つのSASレーンがあります。8x2.5inR710シャーシでは、これはフロントパネルディスクのSASレーンへの1対1のマッピングです。 3.5インチシャーシでは、ポート6と7は未使用です。4ディスクアレイでは、PERCカードに単一のプロセッサとメモリが残っていても、2つのディスクをスロット4と5に移動して、チャネル間でワークロードを分割できます。
通常、ファームウェアの更新は良い考えであり、かなり簡単なプロセスです(ただし、再起動が必要です)。
4ディスクRAID10は、書き込み用に2ディスク、読み取り用に4ディスクのパフォーマンスを提供します(絶対に最良のシナリオ)。 7200 rpm HDDは、75〜100IOpsを提供する必要があります。どんなパフォーマンスが見られますか?読みますか %util
iostat
で100に近い?
一次負荷がデータベースによって生成される場合、それが主に順次になると思われる理由は何ですか?データベースは、ステレオタイプのランダムアクセスの場合です。 iostat
を使用して、平均リクエストサイズを確認できます。 collectl
はさらに、カーネルで行われたI/Oマージに関する情報を提供します。主にシーケンシャル読み取りの期待に同意しますか?
Fsync()カーネルのバグとはどういう意味ですか?
どのファイルシステムを使用していますか?どのマウントオプションですか? noatime
オプションを使用すると、ext [34]の速度が大幅に向上します。これは、アクセス時間の変更により、ファイルの読み取りごとに余分な書き込みが発生する可能性があるためです(最悪の場合、高解像度のタイムスタンプ)。
回答セクション;)
ファームウェアの更新が役立つ場合がありますが、奇跡は期待しないでください。あなたは数パーセントを得るかもしれませんが、
RAID 10は(冗長性を維持したい場合)パフォーマンスに最適なレベルであるため、それ自体で問題が発生することはありません。ただし、パーティションやLVがストライプサイズに揃えられていない場合があります。これにより、小さなランダム読み取りに必要なIOが2倍になる可能性があり(最悪のシナリオ)、あらゆるタイプのI/Oにオーバーヘッドが発生します。
省電力モードはそれほど費用がかからないはずです。おっしゃるとおり、ディスクはビジー状態でスピンダウンできず、CPUはとにかくI/Oを待機しています。
私たちのサーバーの1つには、そのRAIDコントローラーとファームウェアリビジョンがありました。どうやら、ファームウェアの最新バージョンは、書き込みキャッシュバッテリーが適切に充電されないバグを修正しています。バッテリーが充電されていないため、コントローラーはデータを保護するためにライトスルーモードに切り替わり、パフォーマンスに大きな影響を与えます。
ファームウェアを更新し、バッテリーが充電されるまで数時間待ちます。その後、正常に実行されます。
平均CPU負荷を示すツールの使用には注意してください。その数値は確かにボールパークの負荷を確認するための良い出発点ですが、24 CPUシステムで50%の負荷が発生した場合、12 CPUが100%使用されておらず、他の12CPUがアイドル状態になっていることをどのように確認できますか?負荷が10%未満であるにもかかわらず、100%の処理割り込みで1CPUがハンマーで打たれているケースを見てきました。 -マーク