Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

30.6.3. 調整する値

30.6.3.1. CPU/メモリー

30.6.3.1.1. 論理、物理、cpu、ack スレッド数
論理、物理、CPU、および I/O の確認作業は、複数のスレッドに分散できます。その数は、初期の設定中、または VDO デバイスが再起動された場合は後で指定できます。
1 つのコア、つまり 1 つのスレッドは、指定された時間内に限られた量の作業を実行できます。たとえば、1 つのスレッドですべてのデータブロックのハッシュ値を計算すると、1 秒あたりに処理できるデータブロックの数にハード制限が課されます。複数のスレッド (およびコア) にわたって作業を分割すると、ボトルネックが緩和されます。
スレッドまたはコアの使用率が 100% に近づくにつれて、より多くのワークアイテムが処理のキューに追加される傾向があります。これにより、CPU のアイドルサイクルが減る可能性がありますが、個々の I/O 要求のキューイング遅延および待ち時間は通常増加します。一部のキュー理論モデルでは、使用率が 70% または 80% を超えると過剰な遅延が発生し、通常の処理時間よりも数倍長くなる可能性があります。したがって、それらのスレッドまたはコアが常にビジーであるとは限らない場合でも、使用率が 50% 以上のスレッドまたはコアの作業をさらに分散すると役立つ場合があります。
逆の場合、スレッドまたは CPU の負荷が非常に軽い (したがって、非常に頻繁にスリープ状態になっている) 場合、そのための作業を提供すると、追加のコストが発生する可能性が高くなります。(別のスレッドをウェイクアップしようとするスレッドは、スケジューラーのデータ構造に対するグローバルロックを取得する必要があり、プロセッサー間割り込みを送信して別のコアに作業を転送する可能性があります)。VDO スレッドを実行するように設定されているコアが増えると、作業がスレッド間で移動したり、スレッドがコア間で移動したりするときに、特定のデータがキャッシュされる可能性が低くなります。そのため、作業の分散が多すぎるとパフォーマンスが低下する可能性があります。
I/O 要求ごとに、論理スレッド、物理スレッド、および CPU スレッドが実行する作業はワークロードのタイプにより異なるため、システムでは、サービスを受ける予定のさまざまなタイプのワークロードでテストする必要があります。
重複排除に成功した同期モードでの書き込み操作では、新しいデータの書き込みと比較して、余分な I/O 操作 (前に保存されたデータブロックの読み込み)、いくつかの CPU サイクル (新しいデータブロックと比較して一致するか確認)、ジャーナル更新 (LBN を前に保存されたデータブロックの PBN に再マップ) が発生します。非同期モードで重複が検出された場合、上記の読み取りおよび比較操作を犠牲にして、データ書き込み操作が回避されます。重複が検出されたかどうかに関係なく、書き込みごとに発生できるジャーナル更新は 1 つだけです。
圧縮が有効になっていると、圧縮可能なデータの読み取りと書き込みに、CPU スレッドによる処理がさらに必要になります。
すべてゼロバイトを含むブロック (ゼロブロック) は、一般的に発生するため、特別に扱われます。ブロックマップでは、このようなデータを表すのに特殊なエントリーが使用され、ゼロのブロックはストレージデバイスに書き込まれたり、読み取られたりしません。したがって、すべてゼロのブロックを書き込みまたは読み取るテストでは、誤解を招く結果が生じる可能性があります。物理スレッドによる参照カウントの更新はゼロブロックまたは初期化されていないブロックには必要ないため、ゼロブロックまたは初期化されていないブロック (VDO デバイスの作成以降に書き込まれなかったブロック) を上書きするテストについても、程度は低くなりますが、同じことが当てはまります。
I/O 操作の承認は、I/O 操作ごとにコールバックが 1 つ発行されるため、実行中の作業のタイプや操作されるデータに大きく影響されない唯一のタスクです。
30.6.3.1.2. CPU アフィニティーおよび NUMA
NUMA ノードの境界を越えたメモリーのアクセスは、ローカルノードのメモリーのアクセスよりも時間がかかります。Intel プロセッサーがノードのコア間で最終レベルのキャッシュを共有すると、ノード間のキャッシュ競合は、ノード内のキャッシュ競合よりもはるかに大きな問題になります。
top などのツールでは、機能する CPU サイクルと、機能が停止しているサイクルを区別できません。このようなツールは、キャッシュの競合と、低速なメモリーアクセスを実際の動作として解釈します。その結果、ノード間でスレッドを移動すると、スレッドの見かけの CPU 使用率が低下し、1 秒あたりに実行される操作の数が増えるように見える場合があります。
VDO のカーネルスレッドの多くは、1 つのスレッドのみがアクセスするデータ構造を維持しますが、I/O 要求自体に関するメッセージを頻繁に交換します。VDO スレッドが複数のノードで実行されている場合、またはスケジューラーがあるノードから別のノードにスレッドを再割り当てしている場合は、競合が高くなることがあります。VDO スレッドと同じノードで、他の VDO 関連の作業 (VDO への I/O 送信、ストレージデバイスの割り込み処理など) を実行できる場合は、競合をさらに減らすことができます。1 つのノードにすべての VDO 関連の作業を実行するための十分なサイクルがない場合は、他のノードに移動するスレッドを選択するときにメモリーの競合を考慮する必要があります。
可能な場合は、taskset ユーティリティーを使用して 1 つのノードで VDO スレッドを収集します。他の VDO 関連の作業も同じノードで実行できる場合は、競合がさらに減少する可能性があります。この場合、処理に対する要求に対応するために、あるノードで CPU パワーが足りないと、別のノードに移動するスレッドを選択する際に、メモリーの競合を考慮する必要があります。たとえば、ストレージデバイスのドライバーが保持するデータ構造が多数ある場合は、デバイスの割り込み処理と VDO の I/O 送信 (デバイスのドライバーコードを呼び出す bio スレッド) の両方を別のノードに移動させると便利です。I/O 確認スレッド (ack スレッド) と上位レベルの I/O 送信スレッド (ダイレクト I/O を実行するユーザーモードスレッド、またはカーネルのページキャッシュflushスレッド) のペアを保持することも推奨されます。
30.6.3.1.3. 周波数のスロットル調整
消費電力が問題ではない場合は、/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ファイルに文字列の performance を書き込むと良い結果が得られることがあります (存在する場合)。このようなsysfsノードが存在しない場合、Linux やシステムの BIOS により、CPU 周波数管理を設定するためのその他のオプションが提供されることがあります。
特定の作業を実行するために必要な時間は、タスクの切り替えやキャッシュの競合がなくても、CPU が実行している他の作業によって異なる可能性があるため、パフォーマンスの測定は、ワークロードに基づいて頻度を動的に変化させる CPU によってさらに複雑になります。