RAMの使用量（十分な容量があるため）や、誤ってシャットダウンした場合にデータが失われること（電源がバックアップされているため、システムは信頼でき、データは重要ではありません）については心配していません。しかし、私は多くのファイル処理を行っており、パフォーマンスをいくらか向上させることができます。
そのため、ファイルシステムの読み取りおよび書き込みキャッシュにより多くのRAMを使用して、ファイルを積極的にプリフェッチするようにシステムを設定したいと思います（たとえば、ファイルが適切なサイズであるか、少なくともそれ以外の場合は、その大部分を先読みします）、書き込みバッファをフラッシュする頻度を減らします。これを達成する方法（それは可能かもしれません）？
XUbuntu 11.10 x86でext3およびntfs（ntfsをよく使用します！）ファイルシステムを使用しています。
承認された回答：
一般に、ディスクキャッシュのパフォーマンスを向上させることは、全体を除いて、ファイルシステムのキャッシュサイズを増やすだけではありません。 システムはRAMに適合します。この場合、RAMドライブ（tmpfs）を使用する必要があります。 ランタイムストレージ（および起動時にストレージからRAMドライブにシステムをコピーするためのinitrdスクリプト）用に、場合によってはRAMが必要な場合にディスクにフォールバックできるため、優れています。
ストレージデバイスがSSDなのかHDDなのかわかりませんでした。これが私のために働くことがわかったものです（私の場合はsda /homeにマウントされたHDDです およびsdb SSDは/にマウントされています 。
最初に、ストレージからキャッシュへの読み込み部分を最適化します：
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 コマンドは、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を設定しているようです へ 最高のスループットが得られますが、1に設定します 全体的なレイテンシが最高（最低）になります。
これらの調整可能オブジェクトの詳細については、https：//www.kernel.org/doc/Documentation/block/cfq-iosched.txtを参照してください。
2020年のアップデートとカーネルバージョン5.3（cfqは廃止されました）：
modprobe bfq
for d in /sys/block/sd?
do
# HDD (tuned for Seagate SMR drive)
echo bfq > "$d/queue/scheduler"
echo 4 > "$d/queue/nr_requests"
echo 32000 > "$d/queue/iosched/back_seek_max"
echo 3 > "$d/queue/iosched/back_seek_penalty"
echo 80 > "$d/queue/iosched/fifo_expire_sync"
echo 1000 > "$d/queue/iosched/fifo_expire_async"
echo 5300 > "$d/queue/iosched/slice_idle_us"
echo 1 > "$d/queue/iosched/low_latency"
echo 200 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/max_budget"
echo 1 > "$d/queue/iosched/strict_guarantees"
# additional tweaks for SSD (tuned for Samsung EVO 850):
if test $(cat "$d/queue/rotational") = "0"
then
echo 36 > "$d/queue/nr_requests"
echo 1 > "$d/queue/iosched/back_seek_penalty"
# slice_idle_us should be ~ 0.7/IOPS in µs
echo 16 > "$d/queue/iosched/slice_idle_us"
echo 10 > "$d/queue/iosched/fifo_expire_sync"
echo 250 > "$d/queue/iosched/fifo_expire_async"
echo 10 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/strict_guarantees"
fi
done
セットアップは非常に似ていますが、今はbfqを使用しています cfqの代わりに 後者は最新のカーネルでは利用できないためです。 nr_requestsを維持しようとしています bfqを許可するために可能な限り低くする スケジューリングをより正確に制御します。少なくともSamsungSSDドライブは、高いIOPSで実行できるようにするために、かなり深いキューを必要とするようです。
カーネルパッケージlinux-lowlatency-hwe-18.04-edgeでUbuntu18.04を使用しています bfqがあります モジュールとしてのみ使用するため、切り替える前にロードする必要があります。
最近もzramを使用しています しかし、私はzramにRAMの5％しか使用していません。これにより、Linuxカーネルはディスクに触れることなくスワッピング関連のロジックを使用できます。ただし、ディスクスワップをゼロにする場合は、アプリがRAMをリークしたり、お金を無駄にしたりしないようにしてください。
適切なパフォーマンスでディスクからキャッシュにデータをロードするようにカーネルを構成したので、次はキャッシュの動作を調整します。
私が行ったベンチマークによると、blockdevを介して先読みを設定する必要はありません。 まったく。カーネルのデフォルト設定で問題ありません。
アプリケーションコードよりもファイルデータの交換を優先するようにシステムを設定します（これは、全体を維持するのに十分なRAMがあるかどうかは関係ありません。 ファイルシステムおよび すべてのアプリケーションコードおよび RAM内のアプリケーションによって割り当てられたすべての仮想メモリ）。これにより、単一のアプリケーションから大きなファイルにアクセスするための待ち時間よりも、異なるアプリケーション間でスワップするための待ち時間が短縮されます。
echo 15 > /proc/sys/vm/swappiness
アプリケーションをほぼ常にRAMに保持したい場合は、これを1に設定できます。これをゼロに設定すると、OOMを回避するためにどうしても必要な場合を除いて、カーネルはまったくスワップしません。メモリが限られていて、大きなファイル（HDビデオ編集など）で作業している場合は、これを100に近づけるのが理にかなっているかもしれません。
私は最近（2017）、十分なRAMがあれば、スワップをまったく使用しないことを好みます。スワップがない場合、通常、長時間実行されているデスクトップマシンでは200〜1000MBのRAMが失われます。最悪のシナリオの遅延（RAMがいっぱいになったときにアプリケーションコードを入れ替える）を回避するために、それだけ犠牲にするつもりです。実際には、これは私がスワッピングよりもOOMKillerを好むことを意味します。スワッピングを許可/必要とする場合は、/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を大幅に超えて増やすと、パフォーマンスに悪影響を与える可能性がある」と記載されています。
例外： 本当に大量のファイルとディレクトリがあり、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
これらの調整可能オブジェクトの詳細については、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)&