Básicamente, mi pregunta está relacionada con la asignación de memoria para máquinas virtuales Solaris.
Estoy ejecutando un par de servidores web Java Sun ONE 6 antiguos en dos máquinas virtuales Solaris 8. Veo que se está utilizando una cantidad razonable de espacio de intercambio, pero no estoy exactamente seguro de si esto podría indicar la necesidad de agregar más RAM a estas máquinas.
En las horas pico del servicio (normalmente por la mañana), el tiempo de respuesta de la aplicación web que alojan estos servidores aumenta hasta un máximo de 11 segundos (algo perjudicial para una acción de carga de página web relativamente simple). El tiempo medio de respuesta en horas no punta es de unos 5 segundos.
¿Qué podría inferir sobre el uso de RAM para estas máquinas a partir del siguiente resultado? ¿Es esta información razonablemente suficiente? ¿O necesitaría ejecutar otros comandos para descartar la falta de memoria del servidor?
Finalmente, dado que hay una aplicación Java en el centro de la configuración, también pensé en:
1) Rastree la asignación de objetos del montón para detectar posibles pérdidas de memoria.
2) Realice algunos perfiles de rendimiento para ver si esto se relaciona con retrasos en la red. Menciono esto porque la aplicación habla con una única base de datos Oracle, pero dudo que este sea el caso ya que están bastante cerca desde una perspectiva de segmentación de red.
Agradezco cualquier tipo de información y comentarios que pueda proporcionar.
Gracias por tu tiempo y ayuda.
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
Respuesta1
Para determinar si a sus servidores les falta RAM, una métrica útil sería la columna sr en la salida del comando vmstat. Simplemente ejecute algo como vmstat 10 10durante los períodos de referencia y pico (10 muestras cada 10 segundos) y publique el resultado. swap -sLos resultados también serían útiles. Como alternativa a vmstat, es posible que prefiera ejecutar. sar -g 5 5
En cualquier caso, el servidor2 parece carecer de RAM según la salida "superior". Solaris tiene un comando compatible similar a top que también podría ayudar a identificar los consumidores de memoria física y virtual:
prstat -s rss -n 5
prstat -s size -n 5
Respuesta2
Las cosas que me destacan en estas instantáneas son las siguientes:
- Muchos procesos de Perl
- Múltiples procesos de servidor web
- Las máquinas están inactivas en un 98% y un 99%
Estos hechos llevan a las siguientes preguntas...
- ¿Se puede reducir el número de procesos de Perl?
- Supongo que no hay forma de cambiar a un modelo de servidor web con subprocesos.
- ¿Cómo se ve la parte superior del sistema cuando las máquinas están bajo tensión?
Finalmente, haría lo siguiente para rastrear esto:
- Utilice un rastreador de red como Wireshark para ver qué parte del proceso HTTP se está retrasando realmente. ¿Es la conexión? ¿Es la entrega de la página? ¿Es la entrega de una parte dinámica de la página?
- Obtenga una herramienta de estrés HTTP y estrese sus servidores web para ver cómo reaccionan. Mire las respuestas con vmstat y top: me gusta usar la pantalla en una terminal para hacer esto.
¡Buena suerte!
Respuesta3
Siempre he descubierto que la forma más sencilla de realizar un seguimiento del uso de la memoria es la contabilidad del sistema. Puede saltar mucho, por lo que es importante revisarlo al menos una semana para ver el patrón de uso.
Edite el crontab "sys" y verá algunas ejecuciones comentadas del script /usr/lib/sa/sa1. La frecuencia con la que se ejecuta determina la resolución temporal de los datos contables guardados. Normalmente hago algo como esto para un sistema 24x7:
20,40 * * * * /usr/lib/sa/sa1
Eso almacenará estadísticas en /var/adm/sa por día del mes. Ahora usa sar para volcar las estadísticas de la memoria de cualquiera de los días almacenados allí. Digamos que el día 3 fue un día pico para mí:
sar -f /var/adm/sa/sa03 -g
La columna de interés principal es pgscan/s. Si ese número supera los 200 durante largos períodos de tiempo, entonces el sistema no tiene suficiente memoria. A 100 probablemente te beneficiarás de más memoria, pero la degradación no es grave. Hoy en día, con el intercambio de disco mucho más lento que la memoria, trato de mantenerlo en 0, excepto en saltos de corta duración.