私はcat多数のファイルを個別にマージしたいと思いますfile_X。file_1file_100000000000
数が多いため、64個のCPUを持つノードにジョブを分散し、各CPUで並列に実行しました。各タスクはサブフォルダで実行されるため、64のサブフォルダがあります。
驚いたことに、全体の速度は予想よりはるかに遅かった。
私が使用しているシェルスクリプトは、単にfile_X64個のサブフォルダの親ディレクトリにある同じファイルに各タスクを指示するので、複数のCPUが同時に同じファイルを読み込んでいるため、各CPUの読み込み速度が遅くなるのではないかと思います。
ベストアンサー1
はい、いいえ。
ファイルの実際の読み取りは、実行しているプロセッサーの数に関係なく同じ速度で行う必要があります。
ただし、オペレーティングシステムとその構成によっては、ファイルロックが発生する可能性があります。複数のプロセスが同時に読み取りロックを保持できますが、ロックの取得とロック解除は共有ミューテックスブロックで実行する必要があります。システムがこのタイプのロックを実行している場合、プロセッサはファイルにアクセスするためにキューに入れる必要があり、ファイルにはもう興味がないと宣言するためにキューに入れる必要があります。
file_Xが格納されているファイルシステムとそれに結合されたさまざまなファイルとそのファイルシステムをマウントするために使用されるオプションによっては、catがそれを読み取るたびにfile_Xのアクセス時間が更新されることがあります。この場合、file_X inode は各更新前に書き込みロックが解除された後に解除される可能性が高いです。
速度低下のもう一つの考えられる理由は、64のすべての作業がファイルを並列に書き込んでいるためです。このファイルはディスクの異なるポイントになければなりません。ソリッドステートドライブ（SSD）を使用しない限り、ディスク上の書き込みヘッドを大量に移動する必要があります。ファイルは64の異なるディレクトリにあるため、生成されるファイルに加えて更新する必要がある場所は64です。
シェルスクリプトでこのすべてのアクティビティを実行することは、ファイルのすべてのコピーが分岐していることを意味します。 Forkはかなり高価なシステムコールと見なされますが、共有ライブラリを持つシステムでは、すべての共有ライブラリを検索し、すべての共有ライブラリをロードする必要があるexecシステムコールシリーズのコストに比べて何もありません。これは、ファイルが存在するUNIXシステムと構成方法によってファイルに読み取りロックを設定できる別の場所です。