O uso de memória é a principal causa de rotatividade de instâncias no Google App Engine? [fechadas]

Question

Estou experimentando quedas e picos acentuados na contagem de instâncias a cada 30 minutos, embora a taxa de solicitações tenha permanecido estável por 2h a 2.4k RPS. Periodicamente, há muitas solicitações de aquecimento após muitas instâncias serem desligadas ao mesmo tempo. Isso também aumenta nossos custos operacionais devido ao grande número de instâncias ociosas.

• Lançamento do App Engine: 1.8.1
• Número total de instâncias: total de 235 (15 residentes)
• Média de QPS: 9,143
• Latência média: 135,5 ms
• Memória média: 157,9 MBytes

As configurações de desempenho do aplicativo ainda estão nos padrões (instâncias F1, latência de min / max pendente e instâncias de min / max ociosas ainda estão automáticas).

Eu executarei novamente o mesmo teste em instâncias F2 em breve. Enquanto isso:

• Este é um problema conhecido no GAE?
• Isso é causado pelo consumo de memória que é muito alto para F1s?
• O que posso fazer para corrigir esse problema, exceto ir para F2s?
• Como a memória média pode estar acima de 128 MB usando instâncias F1?

contagem de instâncias [F1] RPS[F1] uso total de memória em MB [F1]

AtualizardepoisdeexecutarotesteeminstânciasF2

Duranteasprimeiras2horasdoteste,arotatividadedecasosfoisignificativamentereduzida.Acontagemdeinstânciasfoisignificativamentemaisestável.Nasúltimas2horasdoteste,acontagemdeinstânciasaumentoude250para600,emboraataxadesolicitaçõestenhasidoestávelem2,4kRPS.

contagemdeinstâncias[F1xF2] RPS [F1 vs F2] usototaldememóriaemMB[F1vsF2] milissegundos por solicitação [F1 x F2]

    

Answer 1

Esta informação é tirada em parte de falar com o Google e, da minha própria experiência, não sou funcionário do Google.

Eu descobri que os requisitos de memória de front end do Google são alvos difusos e, geralmente, não são limites rígidos, o que causaria constantes CGs para a maioria dos usuários, já que a maioria dos aplicativos provavelmente os excederia. Eu acho que o seu limite real é de cerca de 170MB antes que a instância corra o risco de ser desligado silenciosamente (eu notei que ele pode rodar cerca de 200MB ocasionalmente, então eu suponho que eles tenham um thread periodico que faz esse trabalho - isso é hipotético Eu não tenho provas de que isso está sendo feito). Se uma instância parece estar fugindo com a memória e eu possuí o servidor que eu sei que eu estaria pensando em matar o processo.

Eu verificaria a quantidade de memória que a maioria das suas instâncias está realmente usando, pois isso pode estar causando a morte das instâncias.

Ao usar um F2, seu servidor pode iniciar e processar solicitações duas vezes mais rápido que um F1, resultando em menos instâncias e devido a um maior limite de memória menor chance de ser morto (novamente minha opinião parece concordar com minha experiência de execução um número de aplicativos de classe empresarial).

Observe também que o Google está lançando (ou testando o RC? !!) uma atualização para seus servidores do GAE 1.8.1 para 1.8.2 e isso pode estar afetando aplicativos como o nosso e é a razão pela qual eu encontrei o seu post, estamos vendo memcache aleatório e latência de resposta de 5 a 20 segundos retornando respostas de memcached totalmente front-end, algo que normalmente seria concluído em < 10 milissegundos (< 80ms com latência de rede). Durante esse lançamento, não esqueça que cada instância de VM / máquina em execução também precisará estar atualizando e servindo outros aplicativos.

Se isso continuar por mais de algumas horas, coletaremos evidências e reivindicaremos os custos - sugiro que os outros façam o mesmo, lembre-se ... O Google se orgulha da confiabilidade do sistema isso é uma das principais prioridades .