web-dev-qa-db-ja.com

Linuxシステムをより強力なファイルシステムキャッシュ用に構成できますか？

RAM=の使用法（十分な量があるため））も、誤ってシャットダウンした場合にデータが失われることも心配していません（電源がバックアップされているため、システムは信頼性があり、データは重要ではありません）しかし、私は多くのファイル処理を行っており、パフォーマンスを向上させることができます。

そのため、ファイルシステムをより積極的にプリフェッチするために、システムがより多くのRAM for file system read and write cachesを使用するように設定します（たとえば、アプリケーションがアクセスしたファイル全体を先読みして）ファイルは正常なサイズであるか、それ以外の場合は少なくともその大きなチャンクを先読みします）、書き込みバッファーをフラッシュする頻度を低くします。これを達成する方法（可能か）

XUbuntu 11.10 x86でext3とntfs（ntfsをたくさん使用しています！）ファイルシステムを使用しています。

linuxfilesystemsperformancefstabsysctl
124
Ivan

wholeシステムがRAMに収まらない場合を除いて、一般的にディスクキャッシュのパフォーマンスを向上させることは、ファイルシステムのキャッシュサイズを増やすだけではなく、RAMドライブ（tmpfsは、ランタイムストレージ用のRAMが必要な場合にディスクにフォールバックできるため、優れています）（およびおそらくストレージからシステムをコピーするinitrdスクリプト）起動時にRAMドライブへ）。

ストレージデバイスがSSDかHDDかはわかりませんでした。これが私にとってうまくいくことがわかりました（私の場合、sdaは/homeにマウントされたHDDであり、sdbは/にマウントされたSSDです）。

最初にload-stuff-from-storage-to-cache部分を最適化します：

HDDの設定は次のとおりです（トグルがある場合は、BIOSでAHCI + NCQが有効になっていることを確認してください）。

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ケースの注目に値するのは、高い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秒後にデータをディスクに書き込もうとしますが、停電時にデータの損失を許容できるため、fifo_expire_asyncを3600000に設定して1時間を通知しますディスクへの遅延は問題ありません。ただし、slice_asyncを低く保つと、読み取りレイテンシが長くなる可能性があります。

hdparmコマンドは、AHCI + NCQが許可するパフォーマンスの多くをAAMが強制終了しないようにするために必要です。ディスクのノイズが多すぎる場合は、これをスキップしてください。

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に設定すると全体の遅延が最高（最低）になるようです。

これらの調整パラメータの詳細については、 https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt を参照してください。

これで、適切なパフォーマンスでディスクからキャッシュにコンテンツをロードするようにカーネルを構成したので、キャッシュの動作を調整します

私が行ったベンチマークによると、blockdevを介して先読みを設定することはまったくありません。カーネルのデフォルト設定で問題ありません。

アプリケーションコードよりファイルデータのスワッピングを優先するようにシステムを設定します（これは、wholeファイルシステムを保持するのに十分な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まで下げることを検討してください（私のシステムには約150Kの10メガピクセルの写真があり、「たくさんの小さなファイル」システムとしてカウントされます）。ゼロに設定しないでください。システムがメモリ不足になった場合でも、ディレクトリ構造は常にメモリに保持されます。これを大きな値に設定することは、常に再読み込みされる大きなファイルがいくつかある場合にのみ有効です（ここでも、十分なRAMのないHDビデオ編集がその例です）。公式のカーネルドキュメントには、「vfs_cache_pressureを100を大幅に超えると、パフォーマンスに悪影響を及ぼす可能性がある」とあります。

例外：非常に大量のファイルとディレクトリがあり、100を超えるvfs_cache_pressure設定ですべてのファイルをほとんどタッチ/読み取り/一覧表示しない場合は、賢くなれ。これは、十分なRAMがなく、ディレクトリ構造全体をRAMに保持できず、通常のファイルキャッシュとプロセス（会社など）に十分なRAMがまだある場合にのみ適用されます。大量のアーカイブコンテンツを持つワイドファイルサーバー）。 vfs_cache_pressureを100以上に増やす必要があると思われる場合は、十分なRAMなしで実行しています。 vfs_cache_pressureを増やすと問題が解決する可能性がありますが、実際の解決策は、RAMを増やすことです。 vfs_cache_pressureを高い数値に設定すると、全体的なパフォーマンスがより安定するために平均パフォーマンスが犠牲になります（つまり、最悪の場合の最悪の動作を回避できますが、全体的なパフォーマンスの低下に対処する必要があります）。

最後に、カーネルにRAMの最大99％を書き込み用のキャッシュとして使用するように指示し、書き込み中のプロセスの速度を低下させる前に最大50％のRAMを使用するようにカーネルに指示します（デフォルトではdirty_background_ratioは10）です。 警告：私は個人的にこれをしませんが、あなたは十分なRAMを持っていると主張し、データを失うことをいとわないです。

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

そして、ディスクへの書き込みstartでも1時間の書き込み遅延は問題ないことを伝えます（ここでも、私はこれを行いません）。

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

これらの調整パラメータの詳細については、 https://www.kernel.org/doc/Documentation/sysctl/vm.txt を参照してください

これらすべてを/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)&
113
Mikko Rantalainen

まず、NTFSの使用を継続することはお勧めしません。Linuxにntfsを実装すると、常にパフォーマンスとセキュリティの問題が発生するためです。

できることはいくつかあります。

  • ext4やbtrfsなどの新しいファイルを使用します
  • bfqなど、ioスケジューラを変更してみてください
  • スワップをオフにする
  • preloadのような自動プリローダーを使用する
  • systemdのようなものを使用して、起動中にプリロードします
  • ...そして何かもっと

多分あなたはそれを試してみたいと思います:-)

16
Felix Yan

先読み：

32ビットシステム：

blockdev --setra 8388607 /dev/sda

64ビットシステム：

blockdev --setra 4294967295 /dev/sda

キャッシュの後ろに書き込み：

echo 100 > /proc/sys/vm/dirty_ratio

これにより、空きメモリの最大100％が書き込みキャッシュとして使用されます。

または、すべてを行ってtmpfsを使用することもできます。これは、RAM=十分な場合にのみ関係します。これを/etc/fstab。 100Gを物理RAMの容量に置き換えます。

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

次に：

mkdir /mnt/tmpfs; mount -a

次に、/ mnt/tmpfsを使用します。

8
Ole Tange

先読みサイズはblockdev --setra sectors /dev/sda1で設定できます。ここで、sectorsは512バイトセクターで必要なサイズです。

6
psusi

私のキラー設定は非常にシンプルで非常に効果的です。

echo "2000" > /proc/sys/vm/vfs_cache_pressure

kernel documentation からの説明：

vfs_cache_pressure

カーネルがディレクトリとiノードオブジェクトのキャッシュに使用されるメモリを再利用する傾向を制御します。

Vfs_cache_pressure = 100のデフォルト値では、カーネルはページキャッシュとスワップキャッシュの再利用に関して「公平な」レートでデントリーとiノードを再利用しようとします。 vfs_cache_pressureを減らすと、カーネルはdentryキャッシュとiノードキャッシュを保持することを優先します。 vfs_cache_pressure = 0の場合、カーネルはメモリの圧力のためにデントリとiノードを再利用することはなく、これはメモリ不足の状態を簡単に引き起こす可能性があります。 vfs_cache_pressureを100を超えて増やすと、カーネルはデントリーとiノードを再利用するようになります。

vfs_cache_pressure 2000では、ほとんどのコンピューティングがRAMおよび非常に遅いディスク書き込みで発生します。

2
user55518

書き込みキャッシュとは関係ありませんが、書き込みには関係があります。

  • Ext4システムの場合、次のことができます ジャーナリングを完全に無効にする

    これにより、特定の更新に対するディスク書き込みの数が減りますが、予期しないシャットダウン後にファイルシステムが不整合な状態のままになり、fsckまたはそれ以上が必要になる場合があります。

ディスク読み取りによるディスク書き込みのトリガーを停止するには：

  • relatime または noatime オプションでマウント

    ファイルを読み取ると、通常、そのファイルの「最終アクセス時刻」メタデータが更新されます。 noatimeオプションはその動作を無効にします。これにより、不要なディスク書き込みが減りますが、そのメタデータはなくなります。一部のディストリビューション（例：Manjaro）では、これをすべてのパーティションのデフォルトとして採用しています（おそらく、以前のモデルのSSDの寿命を延ばすため）。

    relatimeは、atimeを使用するアプリケーションのサポートに役立つヒューリスティックスによると、アクセス時間を更新する頻度が低くなります。これはRed Hat Enterprise Linuxのデフォルトです。

その他のオプション：

  • 上記のコメントで、ミッコは nobarrier オプションでマウントする可能性を共有しました。しかし、イヴァイロ 引用されたRedHat 誰がそれに対して警告するか。どれほどひどい3％を追加したいですか？
1
joeytwiddle