Alternar do Solaris para o Linux reduz a velocidade de backup em 80%. Me ajude a recuperar a velocidade antiga?

Question

Primeiro, uma rápida visão geral do ambiente:

• NetBackup em execução nos servidores Windows (6.5.4 se você se importa) com unidades LTO3.

• O destino de backup costumava ser um Servidor Solaris 9, no hardware da Sun, com o Gerenciador de Volume do Veritas.

• Reconstruída como caixa RHEL5 usando o LVM para gerenciar os volumes, agora em um Xiotech SAN. Com um grande número de volumes.

A natureza dos dados e do aplicativo que a caixa é executada (Optix) é tal que costumava gravar em um volume até atingir um determinado tamanho e, em seguida, esse volume era bloqueado para sempre mais. Por isso, temos \ u01 \ u02 \ u03 ... \ u50. Um tempo atrás (ainda no Solaris Build) nós expandimos e abrimos esses volumes para escrever, assim, em qualquer dia, qualquer um ou todos eles podem mudar. A taxa de transferência de backup costumava ser de 40MB / seg.

Na nova versão do Linux, calculamos a média de algo mais próximo de 8MB / seg. Dado que aqui é 2.1TB de dados aqui que é meio inaceitável, mesmo rodando 4 streams, leva 48 + horas para ser concluído. AE / S no servidor está vinculada. Tenho certeza de que não é a SAN, pois outros clientes que usam a mesma classe de armazenamento e hardware de servidor semelhante estão fazendo backup em um nível de 20MB / s limitado mas tolerável.

Estou procurando ideias para melhorar o rendimento . Os caras do Solaris no escritório ao lado estão culpando o LVM no Linux. Ninguém acha que é o ambiente de backup, porque ainda está funcionando como esperado em qualquer outro lugar. O administrador da caixa agora muito lenta diz "Eu não sei, não sou eu, os usuários dizem que está tudo bem". O que provavelmente é verdade, porque é um sistema de gerenciamento de documentos e eles estão lendo e escrevendo pequenos arquivos.

Solução de problemas de idéias? Alguém viu backup de lixo LVM ou outro desempenho de E / S? Especialmente dado um grande número de volumes contendo um número muito grande (10 milhões talvez) de arquivos pequenos?

Editado para corrigir unidades.

Editado para adicionar:

A NIC está em 1000 / Full (conforme verificada no SO e no Switch)

O sistema de arquivos é EXT3.

Mais informações novas ....

O impacto no desempenho parece estar acontecendo em várias caixas executando LVM e EXT3. Basicamente, todas as novas caixas RHEL5 que construímos este verão.

    

Answer 1

O problema acaba sendo um problema de versão do cliente do NetBackup, mais do que um problema do Linux / LVM. Quando a caixa foi reconstruída como uma caixa linux, o cliente 6.5 foi instalado. Hoje, em resposta a outro problema, atualizamos a versão do cliente para 6.5.4. Estou de volta para extrair dados da caixa a 25-27mb / seg.

Como é que eu poderia ter esquecido a regra número um do NetBackup, ou provavelmente qualquer software de backup, CERTIFIQUE-SE DE QUE SEU CLIENTE E VERSÃO DE SERVIDOR CORRESPONDER se você está tendo um problema que eu não conheço. Talvez eu precise de uma tatuagem.

    

Answer 2

Você usou o sar ou iostat para monitorar o desempenho do disco durante o backup para ver o que o Linux pensa sobre o desempenho do disco?

Que tal usar algum tipo de utilitário de benchmark para testar o desempenho de leitura bruta de arquivos no sistema? Eu acabei de fazer isso, então esta é provavelmente uma maneira terrível de fazer isso, e isso seria apenas para leitura sequencial, mas:

sudo dd if=/u1/some_large_file of=/dev/null

Basicamente, se você usar um utilitário de benchmarking para duplicar a leitura de todos os arquivos pequenos, você pode muito, se é o disco, e de lá ir.

O seguinte não é mais relevante:
Se com 20 kb / s você quer dizer kilobits, a menos que eu estrague isso porque é muito cedo de manhã, seus números não se somam. Você disse que tem 2,1 terabytes a 20 kb / s:

Mesmo que tenha sido apenas 1 TeraByte:

1 TB = 8589934592 bits
8589934592 / 20 (bits a second) = 429496730 seconds
429496730 / 60 (seconds) = 7158278 minutes
7158278 minutes / 60 = 119,304 Hours
119,304 / 24 = 4971 (Days)

Ou se você quis dizer kilobytes:

1 terabyte = 1073741824 kilobytes
1073741824 / 20 kB/s = 53687091 seconds
53687091 seconds = 621 days

Estou bagunçando esses cálculos? (terá que apagar meu post de vergonha se eu estiver :-))

    

Answer 3

qual sistema de arquivos você está usando no (s) volume (s) de LVM?

e como os 10 milhões de arquivos pequenos são armazenados - tudo em um diretório (ou um pequeno número de diretórios) ou espalhados por muitos diretórios e subdiretórios? ("muitos" sendo um número arbitrariamente grande)

a razão pela qual eu pergunto é que alguns sistemas de arquivos têm problemas graves de desempenho quando você tem milhares de arquivos neles. essa é uma causa possível da sua lentidão.

por exemplo, ext2 ou ext3 sem o recurso dir_index ativado (IIRC, dir_index tem sido o padrão no ext3 há vários anos. ele ajuda muito, mas não elimina totalmente o problema).

você pode usar tune2fs para consultar e / ou definir o recurso dir_index para ext3. por exemplo. para consultar:

# tune2fs -l /dev/sda1 | grep feature
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super

se você não vir dir_index nessa lista, será necessário ativá-lo da seguinte forma:

e para definir:

# tune2fs -O dir_index /dev/sda1
tune2fs 1.41.8 (11-July-2009)

(sim, tune2fs só responde aqui imprimindo seu número de versão ... não se incomoda em dizer se a operação foi bem-sucedida ou falhou. não é boa, mas presumivelmente ela imprimiria um erro se falhasse)

finalmente: se isso se tornar o problema, e habilitar o dir_index não ajuda, então você provavelmente precisará considerar o uso de um sistema de arquivos diferente. O XFS é um bom sistema de arquivos de uso geral, e o AFAIK ext4 não tem esse problema. ou seria uma escolha razoável para um substituto fs (embora o ext4 seja bastante novo e mesmo que muitas pessoas o usem sem problemas, não tenho certeza se confiaria em servidores de produção ainda)

    

Answer 4

O próprio LVM realmente não deveria estar impactando isso. Pelo que sei, os bits LVM não são referenciados em todas as operações de metadados, que é onde um atraso entraria para jogar. Está em uma camada diferente no kernel. O LVM afetaria a montagem / desmontagem mais do que afetaria o arquivo abrir / fechar.

Muito mais provável é o que Craig apontou, diretórios grandes prejudicando o desempenho. Linux é um pouco notório por não lidar bem com o problema de grandes diretórios. O VxFS pode manipular até 100K arquivos / diretório rapidamente, onde ext2 / ext3 / reiserfs geralmente começam a desacelerar bem antes disso. Essa é uma área em que uma má escolha no sistema de arquivos para o destino da migração pode prejudicar seriamente o desempenho do backup.

Dito isto, se isso for problema seu, o simples acesso antigo para dentro e para fora desses diretórios também deve ser prejudicado. Pode ser a diferença entre 80ms para abrir um arquivo e 210ms, o que é pouco perceptível para os usuários finais, mas deve estar lá.