私は Linux プログラマーよりも経験豊富な Windows プログラマーです。明らかな何かが欠けている場合はお詫び申し上げます。
Linux を実行している USB2 接続の ext2 ボリュームで 10,000 個を超える小さなファイル (~2->10k) を読み取る必要があります。ディストリビューションはカスタムで、busybox を実行します。
これらの書き込みを改善するためのヒントを期待しています。私は次のことをやっています
handle = open(O_CREAT|O_RDWR)
read(handle, 2kBuffer)
close(handle);
私の読み取りは小さいので、この1つの read() は1回の呼び出しで仕事をする傾向があります
パフォーマンスを向上させるためにできることはありますか? これは USB2 (リムーバブル) ディスク上で動作する Linux のカスタム ディストリビューションであるため、明らかなカーネル設定やマウント オプションが不足している可能性はありますか?
ありがとう！
ファイルから読み取るだけの場合は、ファイルを読み取り専用で開くことをお勧めします。
これとは別に、いくつかの操作を並行して試してみましたか? それは物事をスピードアップしますか？ファイルから読み取ったデータで実際にどのような作業を行っていますか? 他の作業にかなりの時間がかかりますか?
アプリケーションのプロファイルを作成しましたか?
「 atime 」を無効にしてデバイスをマウントします（メタデータの書き込みを発生させるために、実際にはavery read（）呼び出しは必要ありません）。noatimeマウントオプションを参照してください。open（）呼び出しも、ファイルごとに同じことを行うO_NOATIMEフラグを取ります。
（ただし、多くのカーネル/ディストリビューションでは、しばらくの間「relatime」オプションがデフォルトになっており、ほぼ同じスピードアップが得られています）
ディスクからの読み取りはブロックサイズである (そして ext* はブロックのサブアロケーションをサポートしていない) ため、単独でブロックを埋めるにはほど遠い小さなファイルがたくさんある場合は、次のようになります。それらをアーカイブにまとめたほうがよいでしょう。ただし、関連するファイルをグループ化できない場合、これはうまくいかない可能性があります。
ext4を検討しますか？ext3のdir_indexオプションは ext4 の標準であり、同じディレクトリに多くのファイルがある場合は何でも高速化されます。これにより、メタデータ、ディレクトリ、およびファイル ブロックがディスク上でより連続的に配置され、各データ ブロックを追跡するために必要な非データ ブロックの数が大幅に削減されます (ただし、これは小さなファイルよりも大きなファイルの場合に重要です)。小さなファイルのデータを inode にインライン化するという提案がありますが、それは上流にあるとは思いません。
(帯域幅に縛られているのではなく) シークに縛られている場合fadvise(FADV_WILLNEED)は、それらのいずれかから読み取る前に一連のファイルを呼び出すと役立つ場合があります。カーネルはこれをヒントとしてファイル キャッシュに先読みします。ただし、注意してください。キャッシュが保持できる以上の先読みは、無駄で遅くなります。ファイルがいつ追い出されたかを判断するために追加する提案がありfincoreますが、それもまだアップストリームではないと思います.
帯域幅に縛られていることが判明した場合は、ファイルを LZO または gzip で圧縮すると役立つことがあります。CPU は、(LZMA や bzip2 とは対照的に) これらの圧縮方法でディスクを読み取るよりも高速に解凍する必要があります。
ほとんどのディストリビューションは、blockio レベルのキャッシングを低く設定しすぎることを恐れています。設定してみる
blockdev -setra 8192 /dev/yourdatasdev
RAM の使用量が少し増えますが、追加のキャッシングはほぼすべての状況でうまく機能します。大量の RAM がある場合は、より大きな値を使用します。これのマイナス面はまだ見ていません。より多くの RAM を割り当てると、スループットとレイテンシがどんどん良くなります。もちろん、「飽和」レベルはありますが、在庫設定が非常に低い (512) ため、これらのバッファーに大量のメモリを割り当てなくても、改善によって劇的な効果が得られる傾向があります。
速度を低下させるのがメタデータ アクセスである場合、私updatedbは crontab を短い間隔で実行するというばかげたトリックを使用します。これにより、メタデータ キャッシュがウォーム状態に保たれ、すべての有用な情報がプリロードされます。