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 usada, mas não tenho certeza se isso pode indicar a necessidade de adicionar mais RAM a essas máquinas.
Nos horários de pico do serviço (normalmente pela manhã), o tempo de resposta da aplicação web que esses servidores hospedam salta para no máximo 11 segundos (um tanto prejudicial para uma ação relativamente simples de carregamento de página web). O tempo médio de resposta fora dos horários 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 falta de memória do servidor?
Finalmente, como há um aplicativo Java no centro da configuração, também pensei em:
1) Rastreie a alocação de objetos do heap para detectar possíveis vazamentos de memória.
2) Faça alguns perfis de desempenho para ver se isso está relacionado a atrasos na rede. Menciono isso porque o aplicativo se comunica com um único banco de dados Oracle, mas duvido que seja esse o caso, já que eles estão muito próximos do ponto de vista da segmentação de rede.
Agradeço qualquer tipo de visão e feedback que você possa fornecer.
Obrigado pelo seu tempo e ajuda.
Servidor1:
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
Responder1
Para descobrir se falta RAM em seus servidores, uma métrica útil seria a coluna sr na saída do comando vmstat. Basta executar algo como vmstat 10 10durante os períodos de referência e de pico (10 amostras a cada 10 segundos) e postar a saída. swap -sos resultados também seriam úteis. Alternativamente ao vmstat, você pode preferir executar. sar -g 5 5
Em qualquer caso, o server2 parece não ter RAM de acordo com a saída "top". Solaris tem um comando compatível 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
Responder2
As coisas que se destacam para mim nesses instantâneos são as seguintes:
- Muitos processos perl
- Vários processos webservd
- As máquinas estão 98% e 99% ociosas
Esses fatos levam às seguintes questões...
- Você pode reduzir o número de processos Perl?
- Suponho que não há como mudar para um modelo de servidor web encadeado.
- Qual é a aparência da parte superior do sistema quando as máquinas estão sob estresse?
Finalmente, 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 interrompida. É 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 sobrecarregue seus servidores web para ver como eles reagem. Observe as respostas com vmstat e top: gosto de usar screen em um terminal para fazer isso.
Boa sorte!
Responder3
Sempre achei que a maneira mais fácil de rastrear o uso da memória é a contabilidade do sistema. Ele pode pular bastante, por isso é importante revisar 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 frequência com que ele é executado determina o tempo de resolução dos dados contábeis salvos. Normalmente faço algo assim para um sistema 24x7:
20,40 * * * * /usr/lib/sa/sa1
Isso armazenará estatísticas em /var/adm/sa por dia do mês. Agora você usa sar para despejar as estatísticas de memória de qualquer um dos dias armazenados lá. Digamos que o dia 3 foi um dia de pico para mim:
sar -f /var/adm/sa/sa03 -g
A coluna de interesse principal é 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á com mais memória, mas a degradação não é severa. 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.