O que mantém um lado de um rsync tão ocupado?

11

Eu tenho uma máquina Debian na minha LAN servindo como um servidor de backup para os outros. Ele tem quatro HDDs combinados em um dispositivo de software RAID 5 md, em que um LVM, e nesse btrfs. Os backups são feitos usando o rsync e, para um sistema de arquivos grande, levam mais de uma hora. Por muito tempo eu pensei que haveria pouco a fazer sobre isso.

Recentemente, no entanto, notei que a atividade do HDD era muito diferente nos dois extremos da transferência. Enquanto o lado de envio, rodando o Gentoo e usando principalmente o ext4, tinha praticamente nenhum disco IO, o lado receptor estava constantemente ocupado. Como a maioria dos dados não mudaria entre as transferências, acredito que as leituras de metadados devem compor a maior parte dos dados. Mas eu ficaria muito surpreso se ler inodes no btrfs é muito mais trabalhoso do que fazer o mesmo no ext4.

iotop confirmou leituras de disco de cerca de 1-4 MB / s no lado de recebimento, enquanto o lado de envio teve apenas o estouro de 0,5 MB / s ocasionalmente.

Minha pergunta é: alguém pode explicar o que está acontecendo aqui? De preferência, com alguma indicação de como resolver o problema, se possível.

Talvez haja algum sinalizador de btrfs que eu possa usar ou algo similar. Eu preciso de um FS com recursos de snapshots no servidor de backup, e minha tentativa de usar o FreeBSD e o ZFS rapidamente leva a um FS inconsistente, então vejo pouca alternativa para o btrfs no momento. Portanto, as respostas que me dizem para usar ext4 ou zfs podem receber votos positivos, mas não marcar.

Opções de rsync em uso, conforme solicitado por cjm :

--rsync-path='rsync --fake-super'
--archive               # -rlptgoD
--hard-links            # detect and preserve these
--acls
--xattrs
--sparse
--noatime               # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable        # size suffixes, base 1000
--stats

Assim como um monte de regras -f para omitir alguns arquivos.

As opções de montagem do btrfs são relatadas por mount as

rw,nosuid,noexec,noatime,nospace_cache

Em particular, isso inclui o sinal noatime , portanto, não deve haver nenhum documento envolvido, a menos que haja diferenças em alguns arquivos. Eu adicionei esta informação em resposta à resposta por Kyle Jones .

    
por MvG 23.07.2012 / 16:39

3 respostas

3

Uma resposta possível é que o sistema de arquivos remoto é montado por padrão com a opção "atime". O tempo de acesso gravado para tudo o que o rsync remoto acessa combinado com a penalidade de gravação que você sofre com o RAID 5 (paridade de computação significa ler todos os discos RAID antes de gravar em um deles) poderia explicar a ampliação de E / S no lado remoto. / p>

Se eu estiver certo, você pode acelerar as coisas montando o sistema de arquivos remoto com a opção "noatime".

    
por 23.07.2012 / 20:14
1

Eu suspeito que as opções --fake-super. Isso diz ao rsync para armazenar todas as informações de metadados em atributos estendidos em cada arquivo. Eu suspeito que acessar esses atributos é lento. Tente um teste com o rsync para uma raiz sem --fake-super. Você não pode reutilizar o mesmo backup, pois os atributos não serão correspondentes.

    
por 01.07.2014 / 19:11
1

--xattrs / -X foi extremamente lento antes de um commit upstream (ainda não em um release) que foi escolhido no rsync 3.1.2-2 do Debian:

link

link

    
por 25.07.2017 / 00:40