EC2: Problemas de desempenho regulares sem contenção óbvia de recursos

Question

Estamos executando o LAMP + memcached em uma instância do Amazon EC2 do Ubuntu 9.10 x64 xlarge. Este servidor lida com algumas centenas de requisições por segundo, das quais cerca de 60% são estáticas e o restante interage com o mysql e / ou memcached de alguma forma. Este servidor tem sofrido de dois problemas de desempenho possivelmente relacionados e que se mostraram difíceis de diagnosticar. Todas as estatísticas abaixo foram reunidas com CloudWatch, munin ou vmstat / iostat / top, a menos que especificado de outra forma.

1. O primeiro problema é a recorrência de picos regulares de iowait alto a cada poucos minutos, durante os quais a maioria dos processos do apache é simultaneamente iowait por cerca de 10 a 30 segundos antes da desconexão. Não há aumento de disco ou carga de rede durante esse tempo, a fila de disco permanece baixa, não ocorre troca, etc.

2. Mais seriamente, durante os horários de pico, o servidor às vezes experimenta uma drástica perda de desempenho, deixando as solicitações atendidas em ~ 1/3 do que era antes. Uma vez iniciada, essa queda de desempenho pode durar de 2 a 8 horas antes de repentinamente voltar ao desempenho total novamente. Quando isso acontece, é como se o sistema parasse de fazer qualquer coisa. A utilização da CPU, a carga de disco e a carga de rede (conforme relatado pelo CloudWatch) caem simultaneamente em proporção, embora não haja contenção de disco. A fila de disco e a taxa de transferência caem e estão bem abaixo do máximo em todos os momentos, especialmente durante esses mergulhos. EDIT: Esse problema foi resolvido. O Apache estava ficando sem processos de trabalho e, por algum motivo, decidiu que esse era um bom motivo para travar o desempenho completamente, mesmo para aqueles processos que funcionavam bem.

A exceção são leituras de rede, que permanecem tão altas quanto antes, indicando que o servidor ainda está sendo acessado em um volume tão alto quanto antes. Se tentarmos entrar em contato com o servidor quando isso ocorrer, o servidor estará extremamente lento e, muitas vezes, simplesmente desconectará a conexão antes que a solicitação possa ser atendida. Deve-se observar que nem o uso de memória nem a utilização da CPU são especialmente altos a qualquer momento, independentemente de o desempenho estar ou não diminuindo: a% de CPU raramente ultrapassa 10%, o disco não está cheio ou congestionado. Não conseguimos coletar dados sobre o desempenho de troca durante esses mergulhos ainda, mas estamos tentando fazer isso.

Como está, estamos com poucas idéias sobre o que poderia estar causando esses problemas misteriosos e estamos cada vez mais preocupados que isso possa ser um problema (ou má função) do próprio EC2. O fato de que as imensas quedas sempre parecem ocorrer quando o tráfego está chegando ao máximo (embora, novamente, isso não signifique que o servidor está próximo de maximizar seus recursos disponíveis) não pode ser simplesmente coincidência.

Todos os bancos de dados e logs do MySQL são hospedados em um volume do EBS e todo o conteúdo estático é hospedado em um volume separado e diferente do EBS. O Apache atende 160-240 solicitações por segundo e o MySQL 180-200 consultas por segundo, com ~ 0% de consultas lentas e uma taxa de acertos de ~ 90% do memcached. A média de carga tende a ficar em torno de 3. O log de acesso do Apache está desativado para minimizar o acesso ao disco.

    

Answer 1

Provavelmente (como notamos que você encontrou uma resolução com o segundo problema), esses problemas são de configuração ou de outra forma. O EC2 / EBS / qualquer tecnologia de nuvem não está na raiz disso. Estas são questões que você terá em qualquer ambiente, ao contrário da resposta recebida até agora.

Além disso, a Amazon fornece um SLA. Existem situações menores, embora seja extremamente raro que alguns recursos possam entrar em contenção. No entanto, é improvável, considerando o seu uso atual. Eu continuaria fazendo pesquisas de diagnóstico sobre os vários pontos de discórdia e também para falar com as equipes técnicas da Amazon Web Services. Também confira seus fóruns, como geralmente há pessoas muito conhecedoras lá. Você pode estar ciente dos fóruns, mas apenas no caso - confira em 'aqui: link

Além disso, do ponto de vista da arquitetura, você pensou em distribuir essa carga entre várias instâncias do EC2 e balanceamento de carga? Esta é uma opção que deve resolver alguns desses problemas. Também parece que, de qual arquitetura você está discutindo, pode ser melhor se você dividir entre algumas instâncias um pouco menos poderosas e distribuir o trabalho. A outra vantagem é que, se o seu site / serviços continuar a crescer, você estará em uma boa posição para expandir horizontalmente em vez de verticalmente, o que, naturalmente, será limitado.

    

Answer 2

Em primeiro lugar, lamentamos que você esteja tendo sérios problemas com a carga do seu site e, até onde eu saiba, tudo isso deve estar descrito na política de SLA sobre disponibilidade e desempenho de aplicativos. Você deve ter direito a créditos.

O uso de uma nuvem pública compartilhada, como user37899 comentou, não é a plataforma ideal para isso, se for um aplicativo de missão crítica e operação intensiva. A história do compartilhamento não é apenas a certeza de onde seus processos estão sendo executados, além de seu desempenho ser afetado por outros clientes nessa grade. o armazenamento é mais do que provável o recurso compartilhado nessa grade específica que está causando a degradação do desempenho.

A implementação do x64 x64 da Amazon deve ser apropriadamente especificada, no entanto, como mencionado, os recursos de disco, embora compilados pelo volume e pela configuração do RAID, ainda estão sendo acessados a partir de um pool compartilhado.

Eu estaria interessado em saber um pouco mais sobre o que você tem em funcionamento e sobre alguns outros contadores de desempenho e arquitetura de banco de dados para ajudar a melhor servir com uma resposta apropriada para resolver esse problema. e embora me pareça uma solução mais bem servida seria ter pelo menos sua camada de banco de dados em bare metal ou em uma nuvem privada utilizando seu próprio hardware dedicado.

sinta-se à vontade para me enviar uma mensagem Estou disponível para conversar, boa sorte.

    

Answer 3

Como o EC2 é um ambiente de hospedagem compartilhada (seu host compartilha o mesmo hardware com outros hosts), é possível observar uma grande variedade de operações de E / S. Os volumes do EBS são essencialmente NAS e compartilham o mesmo NIC com o tráfego de rede. Cada host físico possui apenas uma conexão de 1 Gb ao backbone. Portanto, você não só tem contenção com as operações de rede de outros clientes, mas também tem contenção de rede com seus e seus discos. Na prática, a contenção de rede normalmente não é um problema, a menos que você esteja compartilhando a caixa com muitos outros clientes de alto tráfego. Você pode contornar um pouco disso usando instâncias maiores (instâncias maiores ocupam uma porcentagem maior da caixa e, portanto, têm menos recursos compartilhados).

Que tipo de iops você está enfrentando no pico e durante esses períodos problemáticos? (coluna sar -d tps)

Qual é o seu tempo de roubar durante esses períodos? (iostat -x 1 ou sar -u).

Você pode aumentar sua capacidade de IOP, o que deve ajudar seu tempo de espera, através do software RAID de vários volumes do EBS juntos. Parece desajeitado, mas na verdade funciona. Isso não resolverá problemas de contenção de rede, mas com seu tráfego, duvido muito que você esteja saturando o link. É possível que outro cliente esteja, no entanto, causando alguma dor.

Às vezes, infelizmente, uma solução simples para esse tipo de problema é simplesmente repassar a instância. É provável que surja em um host diferente com diferentes clientes compartilhados. É uma prática comum para os clientes do EC2 rodarem as instâncias, executarem alguns benchmarks e respinarem se estiverem insatisfeitos com os resultados.

Outra recomendação é dividir as camadas da Web e do banco de dados em diferentes servidores. Um único servidor com web / db geralmente é uma má ideia por um grande número de razões e, neste caso, provavelmente está tornando ainda mais difícil diagnosticar o gargalo.