それらの書き込みはどれほど重要ですか？3 つの提案 (組み合わせ可能) がありますが、そのうちの 1 つは多くの作業が必要であり、そのうちの 1 つは安全性が低くなります...
ジャーナリング
最近のほとんどの Linux ファイルシステムに共通するジャーナリングが原因の 1 つとして、パフォーマンスが低下していると思います。ジャーナリングにより、ファイル メタデータが書き込まれるときにバリアが IO キューに挿入されます。オプションとを使用して、安全性を下げて (場合によっては速度を上げることも)試すことができます。mount(8)barrier=0data=writeback
ただし、クラッシュが発生した場合、ジャーナルは長いfsck(8). またfsck(8)、問題を修正する際にデータを破棄してしまう可能性もあります。一方で、それは軽々しく取るステップではありません。他方では、昔は、ext2ファイルシステムをasync雪の中で両方の方法でジャーナルなしでモードで実行し、それが好きでした。
IO スケジューラ エレベータ
もう 1 つの可能性は、IO エレベータを交換することです。Documentation/block/switching-sched.txtLinux カーネル ソース ツリーを参照してください。短いバージョンは、、、、およびdeadline利用可能です。はカーネルのデフォルトであり、おそらくシステムが使用しているものです。確認してもいい：noopascfqcfq
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
ファイルの最も重要な部分:
As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the deadline or noop schedulers - which
can improve that device's throughput).
To set a specific scheduler, simply do this:
echo SCHEDNAME > /sys/block/DEV/queue/scheduler
where SCHEDNAME is the name of a defined IO scheduler, and DEV is the
device name (hda, hdb, sga, or whatever you happen to have).
The list of defined schedulers can be found by simply doing
a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets:
# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq
スケジューラーを変更する価値はありますが、ジャーナリング要件によってキューに挿入されたバリアによっては、並べ替えがあまりできない場合があります。それでも、データが失われる可能性は低いため、最初のステップになる可能性があります。
アプリケーションの変更
もう 1 つの可能性は、ファイル自体をバンドルするようにアプリケーションを大幅に変更し、より少ない、より大きなファイルをディスクに書き込むことです。奇妙に聞こえるかもしれませんが、(a) iD 開発チームはマップ、テクスチャ、オブジェクトなどを巨大なパッケージにまとめました。zip数百または数千の小さなファイルを読み取るよりもパフォーマンスがはるかに優れているため、いくつかのシステムコールでプログラムに読み取り、展開して実行します。レベル間のロード時間が大幅に短縮されました。(b) Gnome デスクトップ チームと KDE デスクトップ チームは、アイコンとリソース ファイルの読み込みに異なるアプローチを取りました。KDE チームは多数の小さなファイルを何らかの大きなパッケージにパッケージ化しましたが、Gnome チームはそうしませんでした。Gnome チームは起動の遅延が長かったため、カーネルが起動時間を改善するために何らかの努力をしてくれることを望んでいました。カーネル チームは、より少ない、より大きなファイルのアプローチを提案し続けました。