次のコマンドを実行するバックアップスクリプトがあります。
tar -c dir1 dir2 | xz -9 -T0 | gpg -c --batch --passphrase xxx | aws s3 ...
戻り値は常に同じです：tar失敗141（broken pipeエラー）とxz戻り137（詳細モードでも他のエラーメッセージなし）。
rootこのスクリプトは他のサーバーでテストされ、正常に動作します。最初はバックアップ中のデータが破損し、バックアップディレクトリrsnapshot（フォルダ）の一部のソケットファイルが削除された可能性があると思いましたが、それも役に立ちませんでした。
問題が何であるかを知っている人はいますか？
編集：xzパイプから取り出すと機能します。
答え1
簡単に言うと：努力する
xz -9 -T{number of CPU cores - 1} --memlimit={reasonable amount of RAM}
あるいは、マルチコアを使用せずに、より速い速度で同様の圧縮率をxz -T0得ることができます。zstd
ここで起こっていることは、xz残りの部分が生き残ることができるように、オペレーティングシステムのメモリ不足キラーによってあなたが殺される可能性が最も高いです。もちろん、これはパイプを破壊します。 （これはまだ少し驚くべきことです。通常、xz -9最大700 MBのRAMが必要です。これはコアあたりの大量ではありません。）--memlimit=1000MiBRAMの使用量を1000MiB（または何でも）に制限することができます。しかし、、問題が解決したら、「合理的なCPU数」が-9圧縮設定に十分でないため、xzより低いCPU数を選択する必要があることを意味します。そのため、RAMが少なすぎて-9CPUコアあたりのスレッドが少なすぎるのが問題かもしれません。、どちらかを減らす以外に、この問題を解決する方法はありません。
-T0「CPUコアほど多くのスレッドを使う」という意味です。これは結果データを取得してGPGを介して渡すため、非生産的です（GPG自体はそれほど効率的ではなく、CPUコアが1つ必要な可能性が高い）。このawsコマンドを使用すると、次のコマンドが実行されます。それ自体では、TLSは接続を暗号化します（ほとんどの場合、DEFLATE自体を使用して成功しないままデータサイズを縮小しようとする可能性が高い）。
したがって、極端な場合は、-TCPUコアの数を最大1つまで減らす必要があります。
xz通常、最初は使用しないことがあります。これは素晴らしいもちろんコンプレッサーですが信じられない遅い。おそらくストレージGBあたりの費用を支払っていることはわかっていますが、
zstdリソース使用量ははるかに少なく、スループットはより高い同様の結果を得ることができます。
たとえば、私の経験によれば、xz -T0 -6混合イメージ/ソース/バイナリバックアップに置き換えるとzstd -15ファイルサイズが5％大きくなりますが、圧縮速度は約2倍速くなります。しかし、私はzstdのマルチスレッド（8コアシステムで）を使用しません。
必要に応じて必要に応じてマルチスレッドを有効にすることはできますが、AWS転送用にgpgとTLSも実行しているためいいえ（探す）。
答え2
-T0ゼロ以外の数字（CPUの半分以下）を削除または入力することをお勧めします。 xzはほぼ確実にメモリ不足のため、OOMによって終了します。使用すると、-9メモリ使用量も増えます。