Velocidades de disco extremamente lentas Centos 6

Question

A configuração é a seguinte:

• HP Proliant DL380 G7
  
• 6 unidades Sata de 3 TB (nível de vigilância) configuradas com hardware RAID 1 + 0 com o controlador SATA integrado. Modelo é o Seagate SV35
  
• 192 GB de RAM

VMware ESXi 6.0

• Um convidado da VM executando o Centos 6.7 (Kernel 2.6.32-573)

O armazenamento de dados é composto de todo o espaço restante em disco após a instalação do ESXi (pouco menos de 8 TB)

• 1 arquivo VMDK para a partição do sistema em 100 GB
  
• 1 arquivo VMDK para a partição de dados em torno de 7.7TB

No guest CentOS, a partição do sistema é LVM ext4
A partição de dados é um LVM com um único PV, LV e VG ext4

Agora, o problema que tenho é que as velocidades de transferência de dados no disco são extremamente lentas. Tentar copiar um arquivo semi-grande (10-30 GB) de um lugar no LVM para outro no LVM começa com uma taxa de transferência de cerca de 240MB / s, que é a velocidade que eu esperava que ele tivesse, mas apenas depois de alguns segundos (normalmente 30ish) ele cai para 1-4 MB / s, e a visualização iotop me diz que um processo começa a rodar chamado flush-253: 2, o que parece atrasar tudo.

Eu tenho usado     rsync --progress para obter uma melhor imagem das velocidades de transferência em tempo real, mas estou vendo o mesmo resultado com um     cp  operação.

Quando finalmente terminar, tentei executar o mesmo procedimento novamente, com o mesmo arquivo no mesmo local. A segunda vez que a velocidade de transferência indicada do rsync se mantém estável em torno de 240MB / s durante toda a transferência, mas quando o rsync indicou que a transferência do arquivo está completa, ele fica paralisado nesse tempo pelo tempo necessário para concluir o primeiro procedimento de cópia. Eu posso ver o processo flush-253: 2 trabalhando tão duro para ambos os procedimentos.

Agora eu sei que a configuração não é ideal, e eu preferiria ter um disco separado para o sistema ESXi, mas não acho que isso deva ser a causa dessas taxas de transferência extremamente baixas.

Eu procurei informações sobre o processo de flush e, até onde sei, ele basicamente grava dados da memória nos discos reais, mas não encontrei ninguém dizendo que eles experimentaram esse nível de flush. taxas de transferência lentas. O sistema ainda não está em produção e a CPU praticamente não está funcionando, e tem cerca de 100 GB de memória livre para usar quando os procedimentos de cópia são executados.

Alguém tem alguma ideia do que tentar? Eu vi resultados semelhantes em um sistema diferente que é basicamente configurado da mesma maneira, exceto em um hardware completamente diferente (um pouco menor). Eu também tenho um terceiro sistema executando o CentOS 5 e ext3 no LVM, que não tem nenhum problema como este.

EDIT 1: Eu percebo agora tinha lembrado incorretamente, ea partição do sistema também é lvm, mas ainda um volume separado da partição de dados

[root@server /]# mount
/dev/mapper/vg1-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
/dev/mapper/vg1-lv_home on /home type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vg_8tb-lv_8tb on /datavolume type ext4 (rw,nobarrier)


[root@server /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_1-lv_root<br>
                       50G  9.7G   37G  21% /
tmpfs                  91G     0   91G   0% /dev/shm
/dev/sda1             477M   52M  400M  12% /boot
/dev/mapper/vg_1-lv_home
                       45G   52M   43G   1% /home
/dev/mapper/vg_8tb-lv_8tb
                      7.9T  439G  7.1T   6% /datavolume

Atualização 1: Eu tentei aumentar o dirty_ratio até 90, e ainda não vi melhorias. Eu também tentei montá-lo com -o nobarriers, e ainda o mesmo resultado

Atualização 2: Desculpe a todos que estão tentando me ajudar sobre a confusão, agora que eu mesmo já vi, o hardware é na verdade um HP Proliant 380 G7, não sei se isso faz alguma diferença.

Eu também dei uma olhada na configuração do RAID, e parece que estamos usando um controlador RAID P410, e quando eu estou iniciando o gerenciamento do RAID, ele diz

HP Smart array (I think) P410 "SOMETHING", with 0MB in parenthesis

Suponho que isso possa significar que temos 0MB em cache de gravação?

Estou um pouco fora da minha profundidade aqui quando se trata de hardware, você pode adicionar um módulo de cache de gravação (?) para este controlador RAID se um já não existir? Ou você precisa de um novo controlador / mover para uma SAN? Como posso saber se tem um cache de gravação, mas talvez a bateria esteja esgotada?

Atualização 3: Graças às suas sugestões e mais algumas pesquisas, vou agora tentar instalar o arquivo VH do driver de matriz inteligente da HP no ESXi, e espero obter uma imagem mais clara do que tenho. Eu também encontrei a opção no BIOS do sistema para ativar o cache da unidade, então eu posso ter um último recurso, caso aconteça que não temos cache de gravação no controlador.

Atualização 4 (resolvida): Obrigado a todos que sugeriram soluções e, sim, descobriu-se que não havia nenhum módulo de cache presente no controlador de disco.

Para qualquer um que tenha problemas semelhantes, instalei o utilitário hpssacli VIB para ESXi, e poderia com a seguinte saída confirmar o que havia sido sugerido nas respostas.

Placa de Cache Presente: Falso

Smart Array P410i in Slot 0 (Embedded)
Bus Interface: PCI
Slot: 0
Serial Number: 
Controller Status: OK
Hardware Revision: C
Firmware Version: 6.62
Rebuild Priority: Medium
Surface Scan Delay: 15 secs
Surface Scan Mode: Idle
Parallel Surface Scan Supported: No
Wait for Cache Room: Disabled
Surface Analysis Inconsistency Notification: Disabled
Post Prompt Timeout: 0 secs
Cache Board Present: False
Drive Write Cache: Disabled
Total Cache Size: 0 MB
SATA NCQ Supported: True
Number of Ports: 2 Internal only
Driver Name: HP HPSA
Driver Version: 5.5.0
PCI Address (Domain:Bus:Device.Function): 0000:05:00.0
Host Serial Number: 
Sanitize Erase Supported: False
Primary Boot Volume: logicaldrive 1
Secondary Boot Volume: None

    

Answer 1

Não parece que você tenha algum cache de gravação.

Por favor, confirme a geração e o modelo do seu servidor. Se você não tiver um módulo de cache de gravação em Flash (FBWC) no controlador ao qual os discos estão conectados, o desempenho do seu VMware será prejudicado.

A outra questão aqui é o LVM e alguns dos padrões que apareceram no RHEL6 alguns anos atrás. Você vai querer tentar isso com a desativação de barreiras de escrita. O LVM pode ser um problema porque leva as pessoas a evitar o particionamento de seus volumes ... E isso afeta a capacidade de ferramentas como tuned-adm fazerem seu trabalho.

Eu pedi a saída de mount . Você pode por favor postar isso?

Tente montar seus volumes com o sinalizador no barrier . Barreiras de gravação são o padrão para o EL6 no ext4, então esse é o maior problema que você está encontrando.

    

Answer 2

Parece que o seu controlador RAID não tem cache. O principal problema é que a placa RAID de hardware tende a desabilitar, por padrão, o cache DRAM privado do disco.

Em suma, isso significa que, depois de alguns segundos (~ 30, para ser preciso) o pagecache sujo será liberado para o disco, uma tonelada de solicitação de E / S aleatória começa a martelar seu disco mecânico (lento), matando o throughput .

Reabilite o cache DRAM privado de seu disco (é uma opção de controlador RAID, frequentemente) e o desempenho deve subir. Para escrever ainda mais rápido, você pode desativar as barreiras de escrita (com a opção nobarrier mount) mas, infelizmente, sem um cache BBU, desativá-las irá afetar a confiabilidade dos dados em caso de falha do sistema / falta de energia .

EDITAR: dê uma olhada aqui para mais informações.

    

Answer 3

Parece uma duplicata disso:

Flush-0: n processos que causam gargalos em massa

Na verdade, você deve verificar o dirty_ratio, como ele está indo é que as primeiras gravações vão na RAM, então você tem uma taxa de IO muito rápida no começo. Mais tarde, quando a RAM for preenchida até o dirty_ratio, o kernel começará a funcionar no disco.

    

Answer 4

Algumas perguntas:

• Você tem todos os drivers instalados corretamente para o seu DL 360?
• De qual geração é esse servidor? É um servidor G9?
• Que tipo de controlador é esse? Matriz Inteligente XXXXX? Você instalou um módulo de cache para o controlador?
• Você usa HDDs originais da HP?

e duas notas pessoais: - Eu não acho que você realmente alcançará constantes 240 MB / s com 6 drives SATA lentos com 7,2K e um RAID 10.

• O que eu realmente não entendo: Por que você comprou um DL360 com 192GB de RAM (não é barato se for ECC Ram) e depois colocou lá alguns discos rígidos SATA baratos, estúpidos e lentos? Por que você não pegou um 380 e colocou lá alguns discos rígidos SAS 2.5 "mais rápidos lá ... Apenas como um exemplo: eu acho que você poderia ter muito mais velocidade com 10 unidades SAS de 10GB de 900k ou 15 unidades de 600k ... Eu acho que eles seriam muito mais rápidos mesmo se você usasse um RAID 5 ... ok, talvez você não tivesse escolha nisso, mas eu acho que a configuração do servidor não é legal ... Eu sei que essa configuração não pode explique o seu muito lento CP, mas de qualquer maneira ...