Como limitar a E / S do disco durante o backup?

14

Eu tenho um cron que basicamente faz um simples "tar zcf" durante a noite.

O servidor possui:

8 núcleos - CPU Intel (R) Xeon (E5) E5606 a 2.13GHz
25GB RAM
Ubuntu 12.04.2 LTS
RAID 1 de hardware (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) com duas unidades de disco rígido de 2.728TB

Como você pode ver no host de tela de monitoramento:

Durante quase todo o tempo do alcatrão, a E / S do disco vai para> 90% e faz com que todos os outros aplicativos (mysql, apache) diminuam bastante.

2 perguntas:

É normal ter E / S de disco tão alta durante o backup?
Existe uma maneira de limitar a E / S do disco para que outro aplicativo possa continuar funcionando corretamente?

Obrigado!

— acemtp
fonte

11

Além da abordagem geral, ioniceexiste um bom destino de mapeador de dispositivo (ioband), que permite controle preciso sobre a largura de banda de um dispositivo de bloco (DM). Infelizmente, não faz parte do kernel padrão.

Além disso, você provavelmente pode acelerar o alcatrão

Lendo os nomes dos arquivos no cache do disco: find /source/path -printf ""
Lendo os inodes no cache do disco: find /source/path -perm 777 -printf ""
Fazendo o tar ler e gravar blocos maiores de e para o disco, por exemplo, usando um pipe com mbuffer ou buffer (com pelo menos 100 MiB de RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Hauke Laging
fonte

Por que a leitura dos nomes de arquivo / inodes no cache reduz as E / S do disco durante o tar'ing? Eu esperaria que ele aumentasse o IO médio e reduzisse apenas ligeiramente o tempo total.

— Scai 27/05

3

@scai Isso não ajuda com SSDs; minha recomendação refere-se apenas à rotação de discos rígidos. O que mata o desempenho com esses é o movimento da cabeça. Os nomes dos arquivos são armazenados em blocos contínuos, os inodes são armazenados em blocos contínuos e o conteúdo do arquivo é armazenado em blocos contínuos. Se você faz isso da maneira tar, então lê os nomes dos arquivos (e subdiretórios) de um diretório, acessa o inode de um arquivo, o próprio arquivo, o inode do próximo arquivo e o próximo arquivo ... causa mais movimento da cabeça do que ler todos os nomes e inodes um após o outro.

— Hauke Laging

@scai O impacto no desempenho depende do que você faz. É bastante pequeno para backups completos (provavelmente depende do tamanho do arquivo), mas notei uma grande diferença nos backups diferenciais (não no tar, no entanto, pois não uso isso, mas isso deve ser um efeito geral).

— Hauke Laging

Só para ter certeza de que entendi corretamente. Para 1. e 2., basta chamar o comando find e o Linux o armazenará em cache automaticamente?

— Acemtp

@acemtp Isso está correto. though find(por exemplo) -permnão acessará o inode do arquivo. Mas isso permite que a otimização use duas findchamadas. Se você fizer a mesma findligação duas vezes (com pouco tempo), a segunda terminará em segundos (ou menos). Dependendo da quantidade de memória livre e da quantidade de dados armazenados em cache em um determinado ponto, os dados são jogados para fora do cache. Ler demais pode, portanto, apenas diminuir a velocidade da operação. Se você pode alimentar o programa de backup com nomes de arquivos via stdin, pode impedir isso lendo blocos de, por exemplo, 100 arquivos.

— Hauke Laging

13

Espera-se uma alta E / S durante os backups, porque eles geralmente são feitos sobre grandes árvores de arquivos com arquivos grandes. Você pode usar ionicepara priorizar tarefas de E / S no Linux com classes e níveis. O IIRC, classe 2, nível 7 é o nível mais baixo e sem fome que o tornará praticamente invisível para outras cargas e usuários de E / S. Veja man ionicepara uso e detalhes.

— bayindirh
fonte

1

Eu recomendaria abandonar o tar e ir com o rsync (como mencionado por Dogsbody). Eu uso o BackupPC para fazer backup de arquivos nos meus sistemas Windows e Linux e ele suporta o uso do tar e do rsync e cuida automaticamente do link físico para você, além de fornecer uma ótima interface da web.

http://backuppc.sourceforge.net/

— Atari911
fonte

0

Como outros responderam, sim, isso é normal e ioniceé uma boa maneira genérica de não permitir que isso afete seu sistema.

Várias vezes eu vi tarcoisas das pessoas quando elas não precisam. Se alguma porcentagem dos dados que você está copiando não tiver sido alterada desde a última cópia, sugiro que rsynctente.

Isso reduzirá as entradas / saídas copiando apenas os arquivos que foram alterados desde a última cópia. você não poderá reduzir o IO em mais da metade, pois todos os dados ainda precisariam ser lidos, mas reduzirá significativamente a quantidade de dados gravados (o que, dependendo do seu hardware, também pode ser uma operação mais lenta).

Se você deseja cópias / backups separados cada vez que é executado, a opção mais poderosa é –link-dest, que permite vincular arquivos inalterados a um backup anterior. Isso economiza enormes quantidades de espaço no servidor de backup. por exemplo, eu faço backup de uma máquina (Fred), Fred tem um HD de 20 GB e faço backup / copio a unidade inteira, excluindo / proc e / dev. Agora tenho um diretório de 20 GB no meu servidor de backup. No dia seguinte, faço backup de Fred novamente e –link-dest para backup de ontem. O Rsync compara os arquivos remotos com a cópia local e, se exatamente o mesmo, não será necessário transferi-los, mas vinculará o novo arquivo ao arquivo de ontem. Todos os arquivos que foram alterados são copiados de forma recente (ou parcialmente copiados usando o backup de ontem, se possível). Se apenas 100 MB de arquivos foram alterados desde ontem, agora tenho dois diretórios, ambos com 20 GB de arquivos, mas ocupando apenas 20.

Espero que ajude e ainda responda à sua pergunta.

— Dogsbody
fonte