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