Como eu mediria a quantidade de RAM necessária por domínio Glassfish?

Question

Em nosso ambiente de teste, temos muitos aplicativos espalhados por alguns servidores e domínios Glassfish. Para facilitar a criação de versões, eu teria gostado de ter um domínio Glassfish por cliente por aplicativo (como uma versão pesada de várias instâncias de jetty).

Ouvi dizer que o Glassfish usa muitos recursos, por isso gostaria de medir aproximadamente quantas instâncias se encaixariam na RAM disponível. Eu sei que posso fazer isso iniciando as instâncias e observando top output, mas em quais estatísticas específicas devo estar me concentrando para obter uma boa medida do consumo de recursos por instância?

    

Answer 1

Usar top para determinar os requisitos de memória é mais uma arte do que uma ciência exata. Existem duas maneiras principais de fazer isso.

Em ambos os casos, você deseja obter uma linha de base do uso de recursos do sistema antes de iniciar o programa que está investigando (no seu caso, o GlassFish). Então você segue um dos dois caminhos:

Caminho de uso de memória agregada

Esta é a maneira que eu pessoalmente faço, porque eu sinto que dá uma imagem melhor da utilização geral dos recursos. Além disso, se você errar, provavelmente acabará com um número maior em vez de um menor.

Executar top em um terminal em algum lugar e anote a saída do cabeçalho.
Preste atenção especial à memória ativa e com fio:

last pid: 26611;  load averages:  0.50,  0.38,  0.34   up 42+18:51:53  11:44:41
34 processes:  1 running, 33 sleeping
CPU:  0.9% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.1% idle
Mem: 447M Active, 112M Inact, 233M Wired, 22M Cache, 111M Buf, 170M Free
Swap: 2048M Total, 220K Used, 2048M Free

Inicie seu aplicativo de destino e observe a alteração no cabeçalho.

last pid: 26571;  load averages:  0.35,  0.35,  0.33   up 42+18:49:00  11:41:48
34 processes:  1 running, 33 sleeping
CPU:  2.7% user,  0.0% nice,  1.2% system,  0.0% interrupt, 96.1% idle
Mem: 606M Active, 109M Inact, 235M Wired, 22M Cache, 111M Buf, 12M Free
Swap: 2048M Total, 224K Used, 2048M Free

Calcule a alteração na memória usada ( Active + wired ) e livre ( Free ).
Neste caso, a memória usada subiu para 161MB ((447 + 233) - (606 + 235)) e a memória livre diminuiu para 158MB.
(Todas as outras coisas sendo iguais, esses números devem ser iguais ou muito próximos, a diferença sendo feita por alterações nos outros campos, como memória inativa ou espaço em buffer).

O mais pessimista dos números acima é um bom número para se adivinhar a utilização da RAM.

Repita o procedimento acima para instâncias adicionais do programa que você está investigando e plote a alteração em um gráfico para determinar a tendência / curva.

Caminho de uso de memória de instância individual

Este método examina o (s) processo (s) individual (is) associado (s) ao programa que você está investigando.
Prossiga conforme acima, exceto em vez de olhar para o cabeçalho da saída top nos processos individuais que são gerados quando você inicia o programa (eu usarei o Postgres como meu exemplo):

  PID USERNAME     THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 4883 pgsql          1  58    0   181M   146M sbwait  0  24.3H  6.59% postgres
 5842 pgsql          1  44    0   149M   119M sbwait  1 376:03  0.00% postgres
 2051 pgsql          1  44    0 62944K 34836K select  1  21:39  0.00% postgres
 2054 pgsql          1  44    0 31672K  4220K select  1   6:31  0.00% postgres
 2052 pgsql          1  44    0 62944K  5368K select  0   6:00  0.00% postgres
 2053 pgsql          1  44    0 62944K  5484K select  1   1:11  0.00% postgres
 4884 pgsql          1  44    0 62944K  9144K sbwait  1   1:00  0.00% postgres
 1902 pgsql          1  44    0 62944K  5348K select  1   0:46  0.00% postgres

Totalize o tamanho residente ( RES ) para cada processo associado ao seu aplicativo e observe como a RAM é usada. (a diferença entre o tamanho do residente e o tamanho virtual ( VSIZE ou apenas SIZE ).

Existem algumas ressalvas com esse método:

1. Inflação ou deflação de tamanho
   RES ident size não conta a história completa: as bibliotecas compartilhadas são carregadas e não são contadas no tamanho do local. você totaliza o tamanho do residente, como eu disse acima do seu número será abaixo da utilização efectiva.
   As bibliotecas compartilhadas ARE são contadas em tamanho virtual, ( VIRT ou simplesmente SIZE ), mas são contadas em todos os programas que as usam, portanto, se você totalizar o tamanho virtual, seu número estará acima do utilização real - muitas vezes significativamente acima .
   Algumas versões do top também dividem o Swap separadamente - Se o seu programa tiver um vazamento de memória (ou muitos dados que ficam obsoletos e são trocados) isso também pode distorcer seus dados.

2. Processos ausentes
   Se você não contar todos os processos associados gerados como resultado do início do programa, o valor total de uso da RAM será menor do que o real.

Por último, há uma ressalva que se aplica a ambos os métodos: Os aplicativos dinâmicos irão mexer com seus números .
Com isso quero dizer que um programa como o Postgres, ou o Apache, que gera novos threads ou novos processos filhos para atender às solicitações do usuário, não fornecerá uma imagem precisa sob condições estáticas: você precisa colocar uma carga de trabalho no programa para poder medir impacto da carga de trabalho no sistema (essa é outra razão pela qual eu acho o caminho agregado mais fácil: você não precisa caçar todos os filhos, pode apenas ler o cabeçalho à medida que aumenta a carga de trabalho).

O ideal é que você coloque uma carga muito pesada no servidor durante os testes para garantir que cargas de produção normais não façam com que ele comece a espancar seu espaço de troca. Além disso, uma vez feito o dimensionamento, você sempre deve adicionar RAM (use 10% acima dos resultados operacionais piores) e garantir que o sistema tenha RAM suficiente para lidar com isso como uma condição de carga de pico. Lembre-se: a RAM é barata e o tempo de inatividade é caro. Você pode sempre jogar mais RAM no problema durante a construção do servidor e o custo marginal provavelmente será menor do que ter que desligar um sistema para adicionar memória RAM posteriormente.

_{Note que toda a minha saída de top é do FreeBSD - Sua etiquetagem específica pode ser diferente. Consulte a página man do top em seu sistema para descobrir os campos apropriados.}