Problema de desempenho do RAID AWS hs1.8xlarge

Problema de desempenho do RAID AWS hs1.8xlarge

EDIT: Não consigo fazer com que minha instância hs1.8xlarge da AWS forneça E/S de alto desempenho a partir de seu24 unidades locais. Por favor, não me diga como tornar os volumes do EBS mais rápidos.


Contexto: Depois de rodar por alguns anos e com grande sucesso Greenplum single-node edition 4.0.4.0 em uma instância Amazon cc1.4xlarge (vamos chamá-la de gp), achei que seria muito bom aproveitar as vantagens da instância hs1.8xlarge e seus 24 discos rígidos (48 TB brutos) montados localmente, além de 120 GB de RAM. Vamos chamar essa nova configuração de hsgp.

Em gp, montei em volumes RAID-0 20 EBS (dado que os volumes EBS têm backup e são relativamente robustos contra erros de bits, decidi buscar a velocidade máxima).

Agora, imaginei que o novo e brilhante hs1.8xlarge superaria lindamente essa configuração. Até agora eu estava errado. Um monte de consultas pequenas e simples (alguns milhões de linhas cada) chegam em média em torno de 900 ms para gp, 2.800 ms para hsgp. Consultas maiores (6 bilhões de linhas) também mostram vantagem de pelo menos 2 a 3x para gp.

Não sou, de forma alguma, um especialista em níveis de RAID, mas achei que o RAID-10 era uma escolha razoável para as unidades 24x de 2 TB. Eu uso ext4no array raid, com -m .1 -b 4096opções, e ele é montado com -a noatime.

Uma coisa que notei é que, mesmo depois dos três dias que o mdadm levou para resolver ("ressincronizar as unidades"), ele não é tão rápido quanto a Amazon afirma que um hs1.8xlarge pode oferecer: recebo cerca de 305 MB/s de gravação , 705 MB/s de leitura. A Amazon afirma que é possível obter gravação sequencial de até 2,4 GiB/s e leitura sequencial de 2,6 GiB/s.

Alguma ideia para obter uma configuração com melhor desempenho?

Devo abandonar um espaço em disco unificado (uma matriz com 24 unidades) e, em vez disso, ter matrizes menores, uma por fatia do greenplum?

Abaixo estão os detalhes da hsgpconfiguração:

Usei a instância hvm Amazon Linux ( amzn-ami-hvm-2013.09.1.x86_64-ebs (ami-d1bfe4b8)) e atualizei para vmlinuz-3.4.71-63.98.amzn1.

Os parâmetros para ajustar o sistema são fornecidos abaixo.

sysctl.conf:

# greenplum specifics in /etc/sysctl.conf
kernel.sem = 250 64000 100 512
kernel.shmmax = 68719476736
kernel.shmmni = 4096
kernel.shmall = 4294967296
kernel.sem = 250 64000 100 512
kernel.sysrq = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
net.ipv4.tcp_syncookies = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.conf.all.arp_filter = 1
net.core.netdev_max_backlog=10000
vm.overcommit_memory=2

limites:

# greenplum specifics in /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

Detalhes da matriz RAID:

mdadm --create --verbose /dev/md0 --chunk=2048 --level=raid10 --raid-devices=24 /dev/xvd[b-y]

mkfs.ext4 -v -m .1 -b 4096 /dev/md0
mount -o noatime /dev/md0 /data

Responder1

Uma série de coisas que podem explicar essa lacuna de desempenho:

  1. Comparando o desempenho de gravação do volume RAID-10 de 24 fusos com o de 20 fusos RAID-0, seria esperado que o desempenho de gravação do volume máximo fosse 12x e 20x de um único disco, respectivamente. Portanto, uma desaceleração de aproximadamente 2X logo de cara não é uma loucura.
  2. Você fez com que o tamanho do seu bloco fosse de apenas 2 KB. O padrão é 512 KB. (benchmarks de apoio).
  3. A cotação real "Desempenho de leitura e gravação de 2,6 GB por segundo...com tamanho de bloco de 2 MiB." (Fonte). O tamanho do seu bloco ext4 é 4K, que é 512 vezes menor.

Você também omitiu detalhes sobre a configuração do volume com suporte do 20-EBS. Sem especificar o tamanho nem o tipo do volume (ssd GP, IOPS provisionado por ssd ou magnético), ficamos apenas adivinhando o tamanho da equação inteiramente.

Responder2

se diskio for seu gargalo, você poderá obter desempenho e facilidade de gerenciamento muito melhores, executando um volume iops a 4000G/s...... isso é mais fácil de gerenciar do que raid0 em volumes ebs regulares e a capacidade de instantâneo ebs facilita a recuperação. meus benchmarks preliminares mostram iops 4000 mais rápidos que raid0 com 6 fragmentos de 100G, mas não testei completa e consistentemente o suficiente para fornecer números exatos.

informação relacionada