ファイル分割を高速化するためにsplitGNUを使用してLinuxコマンドを実行できますか？parallel
圧縮ファイルを読み取り、行数またはファイルサイズに応じて同じ部分に分割します。
私は次のように努力しています：
zcat file.gz | parallel --pipe --block 2000M 'gzip > {#}.gz'
答え1
習慣。まず、ファイル分割はCPUバインディングではなくIOバインディングである可能性が高いため、問題を解決するためにCPUを追加しても役に立ちません。
gzip解凍自体は並列化できます。unpigz --stdout代わりにgzipを使用してくださいzcat。しかし、ボトルネックが原因でデータがファイルに書き込まれるため、これが大幅にスピードアップできるかどうか疑問です。
分割パイプラインの出力自体は本質的に逐次的なプロセスであるため、並列化は意味がないか理論的にも可能です。
だからあなたができる最速のことは
SIZE=10G # 10 GB output splits
unpigz --stdout | split -b ${SIZE} - outputfile_suffix_
1.事実ストレスを減らすできない実際に並列化 - 基本的に逐次的ですが、チェックサム計算とIO処理は解凍スレッドに加えて別々のスレッドで実行されるため、通常スループットはわずかにunpigz増加します。
答え2
今私の更新された質問を見ることができますか？このアプローチを試しましたが、うまくいきます。少し速いと思います。
あなたは観察しているかもしれませんディスクキャッシュLinuxオペレーティングシステムからfile.gz情報を読みました。ディスクこれは時間がかかることです。ファイルはすでにRAMに保存されているので、はるかに高速です。コールドからブートするログイン後に最初にすることがファイル分割を試みることであれば、どういうわけか最も長い時間がかかるようです。コールドからの起動は、まだfileディスクから読み取られていないためです。このタスクまたはディスクからRAMにロードされる他のタスクを実行すると、そのfileタスクははるかに高速になります。
これは、システム速度、RAM容量（16GB、32GB、768GB）、ファイルサイズ、およびディスクの種類によって混乱する可能性があります。
SSDの代わりに古い7200rpm HDDを使用するサーバー（10 GBサイズ）の経験では、遅延が発生するfile.tar可能性があります。分ファイルに初めてアクセスすると、ディスクI / Oが原因で発生します。
いいえ、分割coreutilsコマンドを並列化できないと思います。
もしあなたのターゲット一部のファイルを処理し、できるだけ早く実行するようにしてください。作るメモリディスク。
mkdir /scratch
mount -t tmpfs -o size=100g tmpfs /scratch
cp /from_wherever/file.gz /scratch
# this copy from disk to /scratch will be the initial time penalty.
# adjust size=?g accordingly, needs to be less than system ram
一度そこにメモリディスクフォローアップは常に早く。cp /scratch/your_output /back_to_wherever_on_disk完了したら、これがRAMであり、再起動時に失われることを認識してください。
答え3
ファイルがまだ圧縮されていない場合：はい。
parallel --pipepart -a bigfile --block 2G gzip '>{#}'
後ですべての部分を並列に処理したいと思います。この場合、bigfile一時ファイルに分割するのではなく、GNU Parallelを直接使用することをお勧めします。
parallel --pipepart -a bigfile --block -1 myprocess data from stdin
各CPUコアを1つの部分に分けてbigfile並列に処理します。