当社は、Web IDE、Web IDEリストユーザーのファイルと同様に、500万人のユーザーがおり、ユーザーのコードファイルを編集してファイルを追加できます。私たちはreaddir、file_get_contents、file_put_contentsなどのこれらの操作を実装するためにphp関数を使用していますが、我々はMooseFSを使用しましたが、プログラムのファイル、特に低速読み込み速度を読みました。小規模ファイル用高速分散ファイルシステム
私たちはファイルシステムを交換する必要があります、私は誰も私に小さなファイルの膨大な数を持っていることを願って、分散ファイルシステムを使用する必要があります。
5百万エントリは、リレーショナルデータベースにとっては小さいです。私はあなたがなぜこれらをファイルシステムに格納する必要性を感じているのだろうと思います。
すべてのユーザーは、起動時にすべてのファイルを読み込む必要がありますか？もしそうなら、私はシステムの設計について疑問に思います。どのように設計しても、この操作はO(N)です。
500万個の小さなファイルをリレーショナルデータベースまたはNoSQLデータベースに入れて、各ユーザーがそのデータベースに接続して特定のものを照会できるようにすると、起動時に繰り返しロードする必要がなくなります。問題が解決しました。
どのような分散ファイルシステムでも、小さなファイルに対する操作を考慮するとき、最も重要な点の1つはネットワーク遅延です。分散ファイルシステムコンポーネント間でできるだけ小さく（0.1msなど）する必要があります。これを実現する最善の方法は、信頼できるスイッチを使用して、すべてのマシンを同じスイッチに接続することです。
はまた、（特にMooseFS中）、分散ファイルシステムに最善のことは、スケーラビリティである - それは意味し、より多くのあなたが持っているノード（とは、より多くのあなたの計算がはすなわち、分散している複数のマウント上で同時に行われる）ことを、クラスタが高速になります。
MooseFSを使用している場合、3.0より小さなファイルの操作が改善されているので、MooseFS 3.0をチェックしてください。これは簡単な方法です。なぜなら、アップグレードの前にマスターサーバー上の/ var/lib/mfs（メタデータ）をバックアップすることを覚えておく必要があるからです。 MooseFSは小さなファイルをうまく扱うことができるので、設定に問題がありますか？
さらに、（小さなファイル操作を考えているにもかかわらず）最も重要なことの1つは、CPUコアが少量で、マスターサーバーのBIOSで省エネオプションが無効なCPUクロック（たとえば3.7 GHzなど） Master Serverはシングルスレッドプロセスなので）。 ChunkserversとClientsでは、状況は異なります。それらはマルチスレッドであるため、マルチコアCPUを使用している間はより良い結果が得られます。
さらに、「仮想マシンとMooseFS」段落4にMooseFS Best practicesに述べたように：
[...]我々は、仮想マシン上でMooseFSコンポーネント（特にマスターサーバー（複数可））実行することはお勧めしません。 。
VM上でMFSを実行すると、結果が悪くなる可能性があります。