より積極的なファイルシステムキャッシング用にLinuxシステムを構成できますか?


119

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

そのため、ファイルシステムの読み取りおよび書き込みキャッシュ用により多くのRAMを使用し、積極的にファイルをプリフェッチするようにシステムを設定する必要があります(たとえば、ファイルが同じサイズまたは少なくともそれ以外の場合はその大きなチャンクを先読みし、書き込みバッファーをフラッシュする頻度を減らします。これを達成するにはどうすればよいでしょうか?

XUbuntu 11.10 x86でext3およびntfs(ntfsをよく使用します!)ファイルシステムを使用します。


6
RAMがたくさんある場合は、パフォーマンスを重視し、データの損失を気にせず、すべてのデータをRAMディスクにコピーしてそこから提供し、クラッシュ/シャットダウン時にすべての更新を破棄します。それがうまくいかない場合は、RAMまたはデータがどれほど重要でないかを "十分"に認定する必要があるかもしれません。
ジェームズヤングマン

1
@Nils、コンピューターはラップトップなので、コントローラーはごく普通のものだと思います。
イヴァン

1
パフォーマンスを大幅に改善する1つの方法は、データの耐久性をスキップすることです。一部のアプリが同期を要求している場合でも、ディスクへの同期を無効にします。これにより、ストレージデバイスで電気の損失が発生した場合にデータが失われます。とにかくそれをしたい場合は、パフォーマンスを向上させるために犠牲にしたい任意のファイルシステムを含めるように実行sudo mount -o ro,nobarrier /path/to/mountpointまたは調整するだけです。ただし、ストレージデバイスにIntel 320 SSDシリーズなどの内蔵バッテリーがある場合、使用してもデータは失われません。/etc/fstabnobarriernobarrier
ミッコランタライネン14

1
Red Hat Enterprise Linux 6では、書き込みバリアのパフォーマンスへの悪影響は無視できる(約3%)ため、nobarrierの使用は推奨されなくなりました。書き込みバリアの利点は、通常、無効にすることのパフォーマンス上の利点を上回ります。また、仮想マシンで構成されたストレージではnobarrierオプションを使用しないでください。 access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/...
Ivailo Bardarov

1
2つのポイント-1)Puppy LinuxやAntiX Linuxなど、DebianやUbuntuをベースにしたLinuxディストリビューションや、オペレーティングシステム全体を階層化されたramdiskパーティション(AUFSやoverlayfs)に入れて透過的に管理する多くのディストリビューションがあります。とても早い!-2)実世界の設計で非常に大規模なシステムの設計で、より多くのキャッシュをスローするとパフォーマンスが低下することがわかりました。ストレージの速度が上がると(SSDなど)、必要な最適なキャッシュサイズが小さくなります。ただし、特定のシステムで実験しなければ、そのサイズを知る方法はありません。増加してもうまくいかない場合は、減らしてみてください。
DocSalvager

回答:


107

一般にディスクキャッシュのパフォーマンスを向上させることは、システム全体がRAMに収まらない限り、ファイルシステムキャッシュサイズを増やすだけではありません。その場合、RAMドライブを使用tmpfsする必要がありますランタイムストレージ用(およびおそらく起動時にストレージからRAMドライブにシステムをコピーするinitrdスクリプト)。

ストレージデバイスがSSDかHDDかはわかりませんでした。これが私のために働くことがわかったものです(私の場合sda、HDDはにマウントされ/homesdbSSDはにマウントされています/)。

最初に、ストレージからキャッシュへのロード部分を最適化します。

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_rqslice_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_idle0-1に設定する必要があります。ゼロに設定すると、すべての順序決定がネイティブNCQに移動し、1に設定すると、カーネルが要求を順序付けできます(ただし、NCQがアクティブな場合、ハードウェアがカーネルの順序付けを部分的にオーバーライドする場合があります)。両方の値をテストして、違いがわかるかどうかを確認します。Intel 320シリーズの場合、最高のスループットslide_idle0提供するように設定するが、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_pressure100を超える必要があると感じる場合は、十分な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)&

3
受け入れられているものよりも十分な情報に基づいた、全体的にはるかに良い答えです!この1は過小評価されている...私はほとんどの人はちょうど彼らが何を理解するために悩まずに、簡単な説明をしたいと思い、本当にやる...
ウラジミールPanteleev

2
@Phpdevpad:さらに、質問は「RAMの使用についてはどちらも気にしません[...]」-Maemoデバイスが適格だとは思いません。
ミッコランタライネン

1
noopやdeadlineはSSDのより良いスケジューラーではありませんか?
rep_movsd

1
@rep_movsdインテルSSDドライブのみを使用しましたが、少なくともこれらのドライブは、CFQなどのよりインテリジェントなスケジューラーで全体的なパフォーマンスを向上させるのに十分なほど低速です。SSDドライブが100Kを超えるランダムIOPSを処理できる場合、高速CPUでもnoopまたはdeadlineを使用することは理にかなっていると思います。「高速CPU」とは、IOでのみ使用可能な3GHzコアが少なくとも複数あるものを意味します。
ミッコランタライネン

1
また、vm kernel docsからこれらのvm調整パラメータについて読むこともできます
-joeytwiddle

16

第一に、Linuxでのntfsの実装はいつでもパフォーマンスとセキュリティの問題になるため、NTFSの使用を継続することはお勧めしません。

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

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

たぶんあなたはそれを試してみたい:-)


1
私はすでにNTFSからext4に完全に一度移動し、唯一のNTFSパーティションをWindowsシステムパーティションにしました。しかし、それは私にとって多くの不便をもたらし、メインデータパーティション(すべてのドキュメント、ダウンロード、プロジェクト、ソースコードなどを格納する)ファイルシステムとしてNTFSに戻りました。パーティション構造とワークフロー(Windowsの使用量を減らすため)を再考することをあきらめませんが、現時点ではNTFSをあきらめることは現実的な選択肢ではないようです。
イヴァン

Windows内でもデータを使用する必要がある場合は、NTFSが唯一のオプションです。(Linux内でVMとしてWindowsを使用できる場合は、他の多くのオプションが利用可能)
Felix Yan

1
これらの想定される問題がNTFSにあるものの要約は有用でした。
underscore_d

2
Linux上のNTFSは、パフォーマンスを除いてほとんど受け入れられます。問題はファイルシステムのパフォーマンスの改善に関するものであると考えると、NTFSを最初に検討する必要があります。
ミッコランタライネン

にもかかわらずbtrfs、最近のファイルシステムを設計されて、私はパフォーマンスが必要な場合ことを避けるだろう。そうでなければbtrfsext4ファイルシステムと同一のシステムを実行しておりext4、現実世界で大きなマージンで勝ちます(同じパフォーマンスレベルの必要性のbtrfs約4倍のCPU時間をext4必要とし、1つの論理コマンドに対してより多くのディスク操作を引き起こします)。ワークロードに応じてext4jfsまたはxfsパフォーマンスを必要とする作業を行うことをお勧めします。
ミッコランタライネン

8

先読み:

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を使用します。


5
3GBまたは2TB先読み?本当に?これらのオプションが何をするのか知っていますか?
Cobra_Fast

1
@Cobra_Fastそれが何を意味するか知っていますか?私には全くわからないので、今興味があります。
syss

3
先読みの設定は、バイトまたはビットではなく、メモリの「ブロック」の数として保存されます。1つのブロックのサイズは、カーネルのコンパイル時(先読みブロックはメモリブロックであるため)またはファイルシステムの作成時に決定されます。ただし、通常、1ブロックには512または4096バイトが含まれます。参照してくださいlinux.die.net/man/8/blockdev
Cobra_Fast

6

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


2

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

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

カーネルのドキュメントからの説明:

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で発生し、ディスクへの書き込みが非常に遅くなります。


4
設定値vfs_cache_pressureが高すぎる(高すぎると思う2000)と、キャッシュに簡単に収まるディレクトリリストなどの単純なものでも、不要なディスクアクセスが発生します。RAMの容量とシステムで何をしていますか?私の答えで書いたように、この設定に高い値を使用することは、RAMが制限されているHDビデオ編集などに意味があります。
ミッコランタライネン14

2
vfs_cache_pressureを100を大幅に超えると、パフォーマンスに悪影響が生じる可能性があります。解放可能なディレクトリおよびiノードオブジェクトを見つけるには、コードをさまざまにロックする必要があります。vfs_cache_pressure= 1000では、あります。」
ミッコランタライネン

1

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

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

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

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

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

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

    relatimeatimeを使用するアプリケーションのサポートに役立つヒューリスティックに従って、アクセス時間の更新頻度を減らします。これはRed Hat Enterprise Linuxのデフォルトです。

別のオプション:

  • 上記のコメントで、ミッコはnobarrierオプションでマウントする可能性を共有しました。しかし、Ivailo はRedHatにそれを警告する人を引用しました。その3%をどれほどひどく欲しいですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.