web-dev-qa-db-ja.com

システムI / Oを過負荷にすることなく10000のファイルを処理するLinuxの最良のファイルシステム

特定のAMD64Linuxは、大量のディスクI/Oで応答しなくなることが知られています( Gentooフォーラム:ディスクアクセス中にAMD64システムが遅い/応答しない(パート2) を参照)、残念ながらそのようなものがあります。

_/var/tmp/portage_ツリーと_/usr/portage_ツリーを別々のパーティションに配置したいのですが、どのFSを選択するのですか?

要件:

_* for journaling, performance is preffered over safe data read/write operations
* optimized to read/write 10000 of small files 
_

候補者:

_* ext2 without any journaling
* BtrFS
_

Phoronixテストでは、 BtrFS は、優れたランダムアクセスパフォーマンスを示しました(XFSよりもはるかに優れているため、CPUへの攻撃性が低い可能性があります)。ただし、XFSを使用するとアンパック操作が高速になるようですが、カーネルツリーをXFSにアンパックすると、再利用されたプロセスやスケジューラーを51%無視しても、システムの反応が遅くなることがテストされました。

なぜReiserFSがないのですか? Googleはこれを行いました(q:reiserfs ext2 cpu):1 Apr 2006 ... Surprisingly, the ReiserFS and the XFS used significantly more CPU to remove file tree (86% and 65%) when other FS used about 15% (Ext3 and ...今は同じですか?

4
kagali-san

Ext4、Btrfs、Reiser4、Reiser3(notailオプション付き)。 XFSは、メタデータを多用する操作(大量のファイルをrmするなど)を吸い込みます。

2
poige

これらのディレクトリは(簡単に復元できるため)実際にはジャーナリングを必要としないため、どのファイルシステムを選択しても、ジャーナリングを無効にすることができます。

Gentooを使用したとき、/ usr/portageにReiserFS3を使用していました。理由は単純です。非常に高速で、非常に小さなファイルを大量に処理する場合に、他のファイルシステムと比較して多くのスペースを節約できました。 (「notail」オプションを使用すると、もちろんこの利点がなくなります)時間の経過とともに、そのファイルシステムのパフォーマンスが低下することに気づきました。これは、/ usr/portageで非常に頻繁に書き込み/削除が行われ、使用するファイルシステムに関係なく、しばらくすると断片化によって速度が低下するためです。そのため、/ usr/portageからtargzを取得し、パーティションを再フォーマットして、targzを再度解凍することがあります...これにより、断片化のない新しい/ usr/portageが得られます。

今でもReiserFSを使用するかどうかはわかりません。おそらくext4(ジャーナリングを無効にした状態)またはext2を使用します。

/ var/tmp/portageについて...十分なRAMがある場合は、それをtmpfsにマップすることをお勧めします。そうすれば、可能な限りRAMを使用しますが、データがRAMに収まらない場合はスワップに移動します。

1
rvdginste

Ext2は他のOSに比べてかなり遅いですが、ファイル数が非常に多い場合にも問題が発生する可能性があります。使用しないことを強くお勧めします。ジャーナリングをオフにしたext4は、まったく別の魚のやかんです。

個人的には、小さなファイルがたくさんあるファイルシステムのReiserfsに傾倒します。これは、この種の操作用に特別に最適化されています。しかし、私は主にWebサーバーを使用しています-アクセスは主に読み取り/専用です(dbにはext4を使用しています)。 CPUの使用率はそれほど大きな問題ではありません。実際、CPUが高いほど、操作を完了するために必要な実際のファイルI/Oが少ないことを示す良い指標になります。

元の記事(あなたが引用したコメントは特に大きなファイルの動作に関連しています)を調べると、私はGentooの専門家ではありませんが、これはPortageとは無関係だと思います。

0
symcbean