到 xz 的焦油管道導致管道損壞
我有一個執行以下命令的備份腳本：
tar -c dir1 dir2 | xz -9 -T0 | gpg -c --batch --passphrase xxx | aws s3 ...返回值始終相同：
tar失敗並返回141(broken pipeerror) 並xz返回137（沒有其他錯誤消息，即使在詳細模式下也是如此）。該腳本已經過測試，可以
root在其他伺服器上執行並且執行良好。最初我認為我正在備份的數據可能已損壞並刪除了備份目錄（這是一個rsnapshot文件夾）中的一些套接字文件，但這也沒有幫助。有誰知道問題可能是什麼？
編輯：如果我
xz從管道中移除它就可以了。
**TL;DR：**試試
xz -9 -T{number of CPU cores - 1} --memlimit={reasonable amount of RAM}或替換
xz -T0為zstd以更高的速度獲得相似的壓縮率，甚至無需使用多個核心。這裡發生的情況很可能是您
xz被作業系統的記憶體不足殺手殺死，以便其餘的可以生存。這當然會破壞管道。（這仍然有點令人驚訝；通常，xz -9最多需要大約 700 MB 的 RAM，每個核心並沒有那麼多）。您可以嘗試--memlimit=1000MiB將 RAM 使用量限制為 1000 MiB（或其他）。但是，如果這樣解決了問題，那說明你的“合理的 CPU 量”不能滿足你的-9壓縮設置的需要，xz只好選擇一個較低的。因此，您的問題可能是-9每個 CPU 核心的 RAM 和執行緒太少，除了減少任何一個之外，沒有什麼可以解決這個問題。
-T0意思是“使用與 CPU 核心一樣多的執行緒”，這會適得其反，因為您獲取結果數據並通過 GPG 將其傳遞（這本身並不太高效，並且很可能需要大約一個 CPU 核心），並通過aws命令，它本身將對連接進行 TLS 加密（並且很可能嘗試使用 DEFLATE 本身減少數據量但未成功）。因此，在極端情況下，
-T最多應與您擁有的 CPU 核心數減一一起使用。一般來說，也許一開始就不要使用
xz。當然，它是一款出色的壓縮器，但速度非常慢。我知道您可能按每 GB 儲存付費，但是：
zstd以更低的資源使用率/更高的吞吐量實現類似的結果。例如，根據我的經驗，將
xz -T0 -6混合圖片/原始碼/二進製備份替換為zstd -15產生 5% 大的文件，但壓縮速度大約快 2 倍，儘管我沒有使用 zstd 的多執行緒（在 8 核機器上）。如果您願意/需要，您仍然可以啟用多執行緒，但看到您也在為 AWS 傳輸執行 gpg 和 TLS，您可能不會（見上文）。