Diagnosticando a memória do servidor Solaris 8 e o uso do espaço de troca

Question

Essencialmente, minha pergunta está relacionada à alocação de memória para máquinas virtuais Solaris.

Estou executando alguns servidores web Sun ONE 6 Java antigos em duas máquinas virtuais Solaris 8. Vejo que há uma quantidade razoável de espaço de troca sendo usado, mas não tenho certeza se isso pode indicar a necessidade de adicionar mais RAM a essas máquinas.

Em horas de pico de serviço (geralmente de manhã), o tempo de resposta do aplicativo da web que esses servidores hospedam salta para no máximo 11 segundos (um pouco prejudicial para uma ação de carregamento de página da web relativamente simples). O tempo médio de resposta em horários fora de pico é de cerca de 5 segundos.

O que você poderia inferir sobre o uso de RAM para essas máquinas a partir da saída abaixo? Esta informação é razoavelmente suficiente? Ou eu precisaria executar alguns outros comandos para descartar a privação de memória do servidor?

Por fim, como há um aplicativo Java no centro da configuração, também pensei em:

1) Rastreie a alocação de objeto do heap para detectar possíveis vazamentos de memória.

2) Faça algum perfil de desempenho para ver se isso está relacionado a atrasos de rede. Eu mencionei isso já que o aplicativo fala com um único banco de dados Oracle, mas eu duvido que esse seja o caso, já que eles são muito próximos de uma perspectiva de segmentação de rede.

Eu aprecio qualquer tipo de insight e feedback que você possa fornecer.

Obrigado pelo seu tempo e ajuda.

Servidor 1:

40 processes:  38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle,  0.4% user,  0.4% kernel,  0.0% iowait,  0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 12676 webservd 112  29   10  616M  242M sleep  103:37  0.48% webservd
 18317 root       1  59    0   23M   19M sleep   67:24  0.08% perl
  9479 support    1  59    0 6696K 2448K cpu/1    0:11  0.05% top
  8012 root      10  59    0   34M  704K sleep   80:54  0.04% java
  1881 root      33  29   10  110M   13M sleep   33:03  0.02% webservd
  7808 root       1  59    0   83M   67M sleep    7:59  0.00% perl
  1461 root      20  59    0 5328K 1392K sleep    6:49  0.00% syslogd
  1691 root       2  59    0   27M  680K sleep    4:22  0.00% webservd
 24386 root       1  59    0   15M   11M sleep    2:50  0.00% perl
 23259 root       1  59    0   11M 4240K sleep    2:42  0.00% perl
 24718 root       1  59    0   11M 5464K sleep    2:29  0.00% perl
 22810 root       1  59    0   19M   11M sleep    2:21  0.00% perl
 24451 root       1  53    2   11M 3800K sleep    2:18  0.00% perl
 18501 root       1  56    1   11M 3960K sleep    2:18  0.00% perl
 14450 root       1  56    1   15M 6920K sleep    1:49  0.00% perl

Servidor 2

 42 processes:  40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle,  0.4% user,  0.8% kernel,  0.0% iowait,  0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  5607 webservd  74  29   10  284M  173M sleep   20:14  0.21% webservd
 15919 support    1  59    0 4056K 2520K cpu/1    0:08  0.09% top
 13138 root      10  59    0   34M 1952K sleep  210:51  0.08% java
 13753 root       1  59    0   22M   12M sleep  170:15  0.07% perl
 22979 root      33  29   10  112M 7864K sleep   85:07  0.04% webservd
 22930 root       1  59    0 3424K 1552K sleep   17:47  0.01% xntpd
 22978 root       2  59    0   27M 2296K sleep   10:49  0.00% webservd
 13571 root       1  59    0 9400K 5112K sleep    5:52  0.00% perl
  5606 root       2  29   10   29M 9056K sleep    0:36  0.00% webservd
 15910 support    1  59    0 9128K 2616K sleep    0:00  0.00% sshd
 13106 root       1  59    0   82M 3520K sleep    7:47  0.00% perl
 13547 root       1  59    0   12M 5528K sleep    6:38  0.00% perl
 13518 root       1  59    0 9336K 3792K sleep    6:24  0.00% perl
 13399 root       1  56    1 8072K 3616K sleep    5:18  0.00% perl
 13557 root       1  53    2 8248K 3624K sleep    5:12  0.00% perl

    

Answer 1

Para descobrir se seus servidores não têm RAM, uma métrica útil seria a coluna sr na saída do comando vmstat. Basta executar algo como vmstat 10 10 durante os períodos de referência e de pico (10 amostras a cada 10 segundos) e postar a saída. As saídas swap -s também seriam úteis. Como alternativa ao vmstat, você pode preferir executar sar -g 5 5 Em qualquer caso, server2 parece não ter RAM de acordo com a saída "top". O Solaris tem um comando suportado semelhante ao top que também pode ajudar a identificar os consumidores de memória virtual e física:

prstat -s rss -n 5
prstat -s size -n 5

    

Answer 2

As coisas que se destacam nesses instantâneos são as seguintes:

• Muitos processos de perl
• Múltiplos processos webservd
• Máquinas com 98% e 99% ociosas

Esses fatos levam às seguintes perguntas ...

• Você pode reduzir o número de processos perl?
• Suponho que não há como alternar para um modelo de servidor da Web encadeado?
• Como é a parte superior do sistema quando as máquinas estão sob estresse?

Por fim, eu faria o seguinte para rastrear isso:

• Use um sniffer de rede como o Wireshark para ver qual parte do processo HTTP está realmente sendo retida. É a conexão? É a entrega da página? É a entrega de uma parte dinâmica da página?
• Obtenha uma ferramenta de estresse HTTP e enfatize seus servidores da Web para ver como eles reagem. Assista as respostas com o vmstat e top: Eu gosto de usar a tela em um terminal para fazer isso.

Boa sorte!

    

Answer 3

Eu sempre achei que a maneira mais fácil de rastrear o uso da memória é a contabilidade do sistema. Pode ser muito útil, por isso é importante rever pelo menos uma semana para ver o padrão de uso.

Edite o crontab "sys", e você verá algumas execuções comentadas do script / usr / lib / sa / sa1. A freqüência com que ele é executado determina a resolução de tempo dos dados contábeis salvos. Eu costumo fazer algo assim para um sistema 24x7:

20,40 * * * * /usr/lib/sa/sa1

Isso armazenará estatísticas em / var / adm / sa até o dia do mês. Agora você usa o sar para despejar as estatísticas de memória para qualquer um dos dias armazenados lá. Diga que o terceiro foi um dia de pico para mim:

sar -f /var/adm/sa/sa03 -g

A coluna de interesse primário é pgscan / s. Se esse número for superior a 200 por longos períodos de tempo, o sistema não terá memória suficiente. Aos 100 você provavelmente se beneficiará de mais memória, mas a degradação não é grave. Hoje em dia, com a troca de disco muito mais lenta que a memória, tento mantê-la em 0, exceto em saltos de curto prazo.