다음 명령을 실행하는 백업 스크립트가 있습니다.
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
최대 700MB의 RAM이 필요하며 이는 코어당 많은 양이 아닙니다.) --memlimit=1000MiB
RAM 사용량을 1000MiB(또는 무엇이든)로 제한해 볼 수 있습니다 .하지만, 문제가 해결되면 "합리적인 CPU 수"가 -9
압축 설정 에 충분하지 않아 xz
더 낮은 CPU 수를 선택해야 함을 의미합니다.따라서 RAM이 너무 적고 -9
CPU 코어당 스레드가 너무 적다 는 것이 문제일 수 있습니다., 둘 중 하나를 줄이는 것 외에는 이 문제를 해결할 수 있는 방법이 없습니다.
-T0
"CPU 코어만큼 많은 스레드를 사용한다"는 뜻입니다. 이는 결과 데이터를 가져와서 GPG를 통해 전달하기 때문에 비생산적입니다(GPG 자체는 그리 효율적이지 않으며 CPU 코어 하나 정도 필요할 가능성이 높습니다). 이 aws
명령을 사용하면 다음 명령이 실행됩니다 . 자체적으로 TLS가 연결을 암호화합니다(대부분 DEFLATE 자체를 사용하여 성공하지 못한 채 데이터 크기를 줄이려고 시도할 가능성이 높습니다).
따라서 극단적인 경우에는 -T
CPU 코어 수를 최대 1개까지 줄여야 합니다.
xz
일반적으로 처음에는 사용하지 않을 수도 있습니다. 이것은훌륭한물론 압축기이지만믿을 수 없는느린. 아마도 스토리지 GB당 비용을 지불하고 있다는 것을 알고 있지만
zstd
리소스 사용량은 훨씬 적고 처리량은 더 높은 유사한 결과를 얻을 수 있습니다.
예를 들어 내 경험에 따르면 xz -T0 -6
혼합 이미지/소스/바이너리 백업으로 바꾸면 zstd -15
파일 크기가 5% 더 커지지만 압축 속도는 약 2배 더 빨라집니다.하지만저는 zstd의 멀티스레딩(8코어 시스템에서)을 사용하지 않습니다.
원하거나 필요한 경우 멀티스레딩을 활성화할 수 있지만 AWS 전송을 위해 gpg 및 TLS도 수행하고 있으므로아니요(찾다).
답변2
-T0
0이 아닌 숫자(예: CPU의 절반 이하)를 제거하거나 입력하는 것이 좋습니다 . xz는 거의 확실하게 메모리가 부족하여 OOM에 의해 종료됩니다. 사용하면 -9
메모리 사용량도 늘어납니다.