一般にディスクキャッシュのパフォーマンスを向上させることは、システム全体がRAMに収まらない限り、ファイルシステムキャッシュサイズを増やすだけではありません。その場合、RAMドライブを使用tmpfs
する必要がありますランタイムストレージ用(およびおそらく起動時にストレージからRAMドライブにシステムをコピーするinitrdスクリプト)。
ストレージデバイスがSSDかHDDかはわかりませんでした。これが私のために働くことがわかったものです(私の場合sda
、HDDはにマウントされ/home
、sdb
SSDはにマウントされています/
)。
最初に、ストレージからキャッシュへのロード部分を最適化します。
HDDのセットアップは次のとおりです(トグルがある場合は、AHCI + NCQがBIOSで有効になっていることを確認してください)。
echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda
HDDの場合は、1つのプロセスで高いスループットを得るにはfifo_expire_async
長い(通常は書き込み)ことに注意する価値がありslice_sync
ます(slice_sync
複数のプロセスがディスクからのデータを並行して待機している場合は、低い数値に設定します)。これslice_idle
は常にHDDの妥協点ですが、ディスクの使用状況とディスクファームウェアに応じて、3〜20の範囲で設定しても問題ありません。低い値をターゲットにすることを好みますが、あまりにも低く設定するとスループットが低下します。このquantum
設定はスループットに大きな影響を与えるように見えますが、これを可能な限り低くして、遅延を適切なレベルに保つようにしてください。設定quantum
が低すぎると、スループットが破壊されます。3〜8の範囲の値は、HDDでうまく機能するようです。読み取りの最悪の場合のレイテンシは(quantum
* slice_sync
)+(slice_async_rq
*slice_async
)カーネルの動作を正しく理解している場合はms。非同期は主に書き込みで使用され、ディスクへの書き込みを遅らせたいので、両方slice_async_rq
とslice_async
非常に低い数に設定します。ただし、設定slice_async_rq
が低すぎると、読み取り後に書き込みを遅らせることができないため、読み取りが停止する場合があります。私の設定は、データがカーネルに渡されてから最大10秒後にディスクにデータを書き込もうとしますが、電力損失時のデータ損失も許容できるため、ディスクへの遅延は1時間でよいfifo_expire_async
こと3600000
を示すように設定されます。slice_async
ただし、それ以外の場合は高い読み取りレイテンシを得ることができるため、低く抑えてください。
このhdparm
コマンドは、AAMがAHCI + NCQが許可するパフォーマンスの多くを殺さないようにするために必要です。ディスクのノイズが大きすぎる場合は、これをスキップしてください。
SSD(Intel 320シリーズ)のセットアップは次のとおりです。
echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync
ここでは、異なるスライス設定の低い値に注目する価値があります。SSDの最も重要な設定は、slice_idle
0-1に設定する必要があります。ゼロに設定すると、すべての順序決定がネイティブNCQに移動し、1に設定すると、カーネルが要求を順序付けできます(ただし、NCQがアクティブな場合、ハードウェアがカーネルの順序付けを部分的にオーバーライドする場合があります)。両方の値をテストして、違いがわかるかどうかを確認します。Intel 320シリーズの場合、最高のスループットslide_idle
を0
提供するように設定するが、1
最高の(最低の)全体的な遅延を提供するように設定するようです。
これらの調整パラメータの詳細については、http://www.linux-mag.com/id/7572/を参照してください。
カーネルを設定して、ディスクから適切なパフォーマンスでキャッシュするものをロードするようになったので、キャッシュの動作を調整します。
私が行ったベンチマークによると、先読みの設定はまったく気にしませんblockdev
。カーネルのデフォルト設定は問題ありません。
アプリケーションコードよりもファイルデータのスワップを優先するようにシステムを設定します(ファイルシステム全体、すべてのアプリケーションコード、および RAM内のアプリケーションによって割り当てられたすべての仮想メモリを保持するのに十分なRAMがある場合は問題ありません)。これにより、単一のアプリケーションから大きなファイルにアクセスする場合のレイテンシーよりも、異なるアプリケーション間でスワップするためのレイテンシーが減少します。
echo 15 > /proc/sys/vm/swappiness
アプリケーションをほぼ常にRAMに保持したい場合は、これを1に設定できます。これをゼロに設定すると、OOMを避けるために絶対に必要でない限り、カーネルはまったくスワップしません。メモリが制限されていて、大きなファイル(HDビデオ編集など)で作業している場合、これを100に近い値に設定するのが理にかなっているかもしれません。
私は最近(2017)十分なRAMがあればスワップをまったく持たないことを好みます。スワップがない場合、通常、長時間実行されているデスクトップマシンでは200〜1000 MBのRAMが失われます。最悪のシナリオレイテンシ(RAMがいっぱいになったときにアプリケーションコードを交換する)を避けるために、私はそれを犠牲にしたいと思います。実際には、これはスワップよりもOOM Killerを好むことを意味します。スワップを許可/必要とする場合/proc/sys/vm/watermark_scale_factor
、レイテンシーを回避するために、を増やすこともできます。100〜500の値をお勧めします。この設定は、CPU使用率をスワップレイテンシの低下と引き換えると考えることができます。デフォルトは10で、可能な最大値は1000です。値が大きいと(カーネルのドキュメントによる)、kswapd
プロセスのCPU使用率が高くなり、全体的なスワッピングレイテンシが低くなります。
次に、いくつかのRAMを解放する必要がある場合に備えて、ファイルの内容よりもディレクトリ階層をメモリに保持することを優先するようカーネルに指示します(再び、すべてがRAMに収まる場合、この設定は何もしません):
echo 10 > /proc/sys/vm/vfs_cache_pressure
セッティング vfs_cache_pressure
ほとんどの場合、カーネルはキャッシュからファイルの内容を使用する前にディレクトリ構造を知る必要があり、ディレクトリキャッシュをすぐにフラッシュするとファイルキャッシュが無価値になります。小さなファイルがたくさんある場合は、この設定で1まで下げることを検討してください(私のシステムには10万ピクセルの写真が約150Kあり、「小さなファイルがたくさんある」システムとしてカウントされます)。システムをメモリ不足にした場合でも、ゼロに設定しないでください。ディレクトリ構造は常にメモリに保持されます。これを大きな値に設定するのが賢明なのは、常に再読み込みされている大きなファイルが数個しかない場合です(やはり、十分なRAMのないHDビデオ編集が例になります)。カーネルの公式ドキュメントには、「
例外:本当に大量のファイルとディレクトリがありvfs_cache_pressure
、100を超えるすべてのファイル設定をタッチ/読み取り/リストすることはめったに賢明ではない場合があります。これは、十分なRAMがなく、ディレクトリ構造全体をRAMに保持できず、通常のファイルキャッシュとプロセスに十分なRAMが残っている場合にのみ適用されます(例:アーカイブコンテンツが多い会社全体のファイルサーバー)。vfs_cache_pressure
100を超える必要があると感じる場合は、十分なRAMなしで実行しています。増やすvfs_cache_pressure
ことが役立つ場合がありますが、唯一の本当の修正は、RAMを増やすことです。たvfs_cache_pressure
(つまり、あなたが本当に悪い最悪の場合の動作を避けるが、悪化し、全体的なパフォーマンスに対処することができます)全体のより安定した性能を有するため、高い数の犠牲平均的なパフォーマンスに設定。
最後に、カーネルに書き込みのキャッシュとしてRAMの最大99%を使用するように指示し、書き込み中のプロセスを遅くする前にRAMの最大50%を使用するようカーネルに指示します(デフォルトはdirty_background_ratio
です10
)。警告:私は個人的にはこれを行いませんが、十分なRAMがあり、データを失うことをいとわないと主張しました。
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
また、ディスクへの書き込みを開始するのに1時間の書き込み遅延でもかまわないことを伝えます(繰り返しますが、これは行いません)。
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
これらのすべてを/etc/rc.local
最後に追加し、以下を含めると、ブート後すぐにすべてがキャッシュに入れられます(ファイルシステムが実際にRAMに収まっている場合にのみこれを行います)。
(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&
または、より簡単に機能する少し単純な代替手段(キャッシュのみ/home
と/usr
のみを使用し/home
、/usr
実際にRAMに収まる場合のみ):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&