Disclaimer: I work at www.mosoplot.com, which automates most of the capacity planning needed here. I've used some
charts from MOSOplot to demonstrate how to do this.
É assim que faço planejamento de capacidade para servidores da Web.
A primeira consideração é que o uso do Htop / top não é adequado para este tipo de análise. Eles só mostram a visão de curto prazo mais extrema, o que é ótimo para análise de desempenho, mas fede a planejamento de capacidade. Você realmente precisa examinar um período de tempo mais longo para julgar isso com precisão. É como provar algumas pessoas para determinar a composição religiosa de um país. Como você sabe que o curto período que você estava assistindo era representativo do que está acontecendo com o servidor no resto do tempo? E quando você está dormindo? Você sabe mesmo se é o horário de pico ou não?
O Htop também usa apenas um intervalo de 2 segundos por padrão. Então picos vêm e vão, e eles podem ou não ser importantes. Realmente, o intervalo mínimo para planejamento de capacidade seria de 5 minutos, mas eu prefiro 1 hora. Isso suavizará os picos para mostrar a tendência subjacente. Isso é o que você precisa planejar contra. No entanto, se você tiver motivos para acreditar que há tendências de curto prazo (por exemplo, se todas as transferências ocorrerem por 10 minutos no início de cada hora), então, por todos os meios, observe isso.
Etapa 1: colete os dados e armazene-os.
O MOSOplot usa o agente collectd, que é capaz de coletar métricas do apache, bem como métricas do sistema.
Para obter as estatísticas do apache (tempo de resposta e volumes), você pode usar o plug-in collectd tail, que será lido nos arquivos de log do apache e extrairá os dados de que você precisa. Existe um plugin apache dedicado, mas ele não recebe os tempos de resposta.
Algo como isso deve ser um começo, junto com as alterações de configuração descritas por Tom H para incluir% D.
LoadPlugin tail
<Plugin "tail">
<File "/var/log/apache2/access.log"> <-- PUT IN CORRECT FILENAME
Instance "apache"
<Match>
Regex "GET.*?\s([0-9\.]+)\s[0-9\.]+$"
ExcludeRegex "\s/(favicon|wp-)"
DSType "GaugeAverage"
Type "response_time"
Instance "last_byte"
</Match>
</File>
</Plugin>
Etapa 2: observe as principais métricas de recursos
- Tempo de resposta
- número de transações
- Utilização da CPU
- Utilização de memória
A métrica número um a ser observada é o tempo de resposta - a menos que seu aplicativo seja um sistema em lote e, nesse caso, você pode ignorar isso.
Tente correlacionar a utilização da CPU e da memória com o tempo de resposta. Isso lhe dará uma idéia de quando seu sistema irá quebrar. O tempo de resposta pode chegar a 5x normal, mas depois disso pode se deteriorar rapidamente. Algumas aplicações podem até não lidar com isso, por isso depende.
Aqui está um link para um gráfico que mostra um exemplo de comparação da CPU com os hits do servidor da Web / minuto. Neste caso, os volumes são baixos e parece que podemos chegar confortavelmente a 15 acertos / minuto.
cpu v hits / minuto
Etapa 3: quando atualizar
Se você não conseguiu coletar tempos de resposta, precisará usar limites fixos. Definitivamente, NÃO espere até que a CPU e / ou a memória estejam limitando a capacidade total. Para começar, provavelmente começaria a degradar em torno de 60% (média horária). Em segundo lugar, a Amazon usa o modo burst em alguns de seus sistemas na marca de 60%, o que é uma boa indicação de que eles consideram esse um bom limite. Se você está freqüentemente excedendo o nível de burst, então você deve pensar em atualizar.
A memória deve estar OK em torno de 90%, mas dado que o apache pode às vezes ter problemas OOM (nginx é melhor nisso), então eu ficaria mais feliz com 70% de pico de uso.
O Apache tende a ser bastante volátil com o uso da memória. Em um servidor da Web que monitoramos, acabamos mudando para o nginx porque era uma instância pequena com apenas 1GB de RAM, e o apache estava sofrendo erros de OOM. Aqui está um gráfico mostrando o quanto o uso de RAM estava pulando sob o apache comparado ao nginx.
Variável de memória com o apache v nginx
Outra coisa para pensar aqui é a rapidez com que você pode obter aprovação para atualizar. Embora, na verdade, a atualização na AWS possa ser rápida, supondo que seu aplicativo seja escalonável, obter a aprovação para atualizar na maioria dos clientes com quem trabalho é, bem, glacial! Dê a si mesmo algumas semanas / meses de vantagem, se é isso que você precisa.
