Início / unix / Perguntas / 679753
Accepted
manifestor
Asked: 2021-12-02 03:54:57 +0800 CST

Tubo de alcatrão para xz resulta em tubo quebrado

  • 772

Eu tenho um script de backup que executa os seguintes comandos:

tar -c dir1 dir2 | xz -9 -T0 | gpg -c --batch --passphrase xxx | aws s3 ...

Os valores de retorno são sempre os mesmos: tarfalha com 141( broken pipeerro) e xzretorna 137(nenhuma outra mensagem de erro, mesmo no modo detalhado).

O script é testado, roda como roote funciona bem em outros servidores. Inicialmente, pensei que os dados que estou fazendo backup poderiam estar corrompidos e excluí alguns arquivos de soquete dentro do diretório de backup (que é uma rsnapshotpasta), mas isso também não ajudou.

Alguém tem ideia de qual pode ser o problema?

EDIT: Se eu remover xzdo tubo, funciona.

pipe tar

2 respostas

  1. Best Answer

    TL;DR: tente

    xz -9 -T{number of CPU cores - 1} --memlimit={reasonable amount of RAM}

    ou substitua xz -T0por zstdpara obter taxas de compactação semelhantes em velocidades mais altas, mesmo sem usar vários núcleos.

    O que acontece aqui é muito provável que você xzseja morto pelo assassino sem memória do seu sistema operacional, para que o resto possa sobreviver. Isso, claro, quebra o tubo. (Ainda é um pouco surpreendente; geralmente, xz -9requer no máximo 700 MB de RAM, o que não é muito por núcleo). Você pode tentar --memlimit=1000MiBlimitar o uso de RAM a 1000 MiB (ou qualquer outro). No entanto , se isso resolver o problema, significa que sua "quantidade razoável de CPU" não pode atender às necessidades de sua -9configuração de compactação e xzteve que escolher uma menor. Então, seu problema provavelmente é que você tem muito pouca RAM para -9e um thread para cada núcleo de CPU , e nada pode resolver isso, além de reduzir qualquer um.

    -T0significa "usar tantos threads quantos núcleos de CPU", o que é contraproducente, pois você pega os dados resultantes e os passa pelo GPG (que não é muito eficiente e possivelmente precisará de cerca de um núcleo de CPU para si), e através do awscomando, que por si só fará a criptografia TLS para a conexão (e possivelmente tentará sem sucesso reduzir o volume de dados usando o próprio DEFLATE).

    Portanto, no caso extremo, -Tdeve ser usado no máximo com o número de núcleos de CPU que você possui menos um.

    Geralmente, talvez não use xzpara começar. É um excelente compressor, com certeza, mas é incrivelmente lento. Eu sei que você provavelmente está pagando por GB de armazenamento, mas:
    zstdobtém resultados semelhantes com um uso de recursos muito menor/taxa de transferência mais alta.

    Por exemplo, na minha experiência, substituir xz -T0 -6um backup misto de imagem/código-fonte/binário por zstd -15arquivos 5% maiores, mas compactação aproximadamente 2 vezes mais rápida, embora eu não tenha usado multithreading com zstd (em uma máquina de 8 núcleos).

    Você ainda pode habilitar o multithreading, se quiser/precisar, mas vendo que também está fazendo gpg e TLS para a transferência da AWS, provavelmente não (veja acima).

    • 2

  2. Eu recomendo remover o -T0ou colocar um número lá diferente de 0 (como talvez metade do seu cpus ou menos). xz está quase certamente ficando sem memória e sendo morto pelo OOM. O uso -9também aumenta o uso de memória.

    • 0

relate perguntas