Creo que la versión de Solaris que estamos ejecutando es demasiado antigua para reportar robo de tiempo en la parte superior. ¿Existe alguna manera de obtener esta información en esta versión anterior de Solaris? Aquí está la información de la versión básica:
-bash-3.2$ uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32
No tengo ninguna experiencia real en estos sistemas Sun VM, por lo que podría estar entendiendo mal las cosas y podría haber una mejor manera de hacer lo que necesito en esta situación. Al aplicar mi modelo mental de Intel, sospecho que nos estamos quedando fuera de la CPU, pero ¿cómo puedo medir eso?
Actualizar
Perdón por la terminología intelectual. Básicamente, estamos ejecutando dos máquinas virtuales en un solo blade, donde una es un servidor de aplicaciones y la otra proporciona soporte SSO para la aplicación. Tenemos momentos en los que el servidor de aplicaciones se ralentiza significativamente y también tenemos momentos en los que la aplicación SSO de terceros se arruina.
También hay silos y políticas involucradas, por lo que no tengo visibilidad del host SSO ni de la capa de hardware real.
Mi hipótesis operativa actual es que cuando la aplicación SSO se vuelve loca, ocupa tanto la CPU que el servidor de aplicaciones no puede obtener suficiente tiempo de cálculo real para mantenerse al día con la carga. Analicé los registros de GC de la aplicación y una cosa que se destacó fueron entradas como esta:
[Times: user=0.71 sys=1.36, real=1.47 secs]
Esto es con 10 subprocesos de trabajo de GC paralelos, normalmente user >> real >> sysy una de las causas del patrón de tiempo impar es una máquina virtual en la que no se puede obtener suficiente CPU. (No estamos intercambiando y todos los sistemas están basados en SSD, por lo que las esperas de IO no son un problema).
En este punto necesito obtener datos que me ayuden a probar esta teoría y, en mi mente de Linux, simplemente marcaría el st% en la parte superior. Buscar en Google también dice que en la versión moderna de Solaris podría hacer lo mismo. Mi problema es que no estamos ejecutando esa versión moderna de Solaris.
Respuesta1
Su verdadero problema aquí parece ser la desaceleración de su rendimiento. Y el tiempo de robo probablemente no tenga sentido en un servidor Solaris 10 T1000/T2000.
Para saber si está ejecutando en una zona, use el /usr/bin/zonenamecomando (la ubicación puede ser diferente en diferentes versiones de Solaris; verifique también /bin, /sbin/y /usr/sbin.) Si zonenamedevuelve algo distinto a global, está ejecutando en una zona.
Si por alguna razón no tienes acceso al zonenamecomando, hay varios pscomandos que puedes usar para ver si estás en una zona. Primero, busque init:
ps -ef | grep init
Si eso no localiza un initproceso con un PID de 1, estás en una zona. También puedes buscar zsched(IIRC):
ps -ef | grep zsched
Si eso devuelve un proceso que es su propio padre (tanto PID como PPID son iguales y mayores que 1), entonces estás ejecutando en una zona.
Si estás en una zona, es posible que te encuentres con limitaciones de recursos que te ralenticen. Sin embargo, no es probable que ese sea el caso.
Quédemás¿Se está ejecutando en el servidor? Incluyendo otras zonas. He visto problemas de rendimiento realmente desagradables en servidores Sun serie T similares a los que estás describiendo, causados por interacciones entre ZFS ARC y aplicaciones que utilizan páginas de memoria enormes, como una base de datos Oracle.
El ZFS ARC utiliza páginas de memoria de 4k, por lo que fragmenta la memoria, y lo haráTODOla memoria de su servidor. Si su servidor entra en ese estado y un proceso requiere una cantidad significativa de páginas de memoria grandes, el kernel tiene que fusionar un montón de páginas pequeñas en otras grandes, lo que implica mover mucha memoria. Y todo se hace en un solo subproceso. Y cualquier subproceso en uno de los primeros servidores de la serie T esLENTOya que los servidores fueron diseñados para manejar una gran cantidad de subprocesos con grandes latencias, como un servidor web o un servidor de bases de datos que maneja muchas conexiones a través de una red.
Entonces, el núcleo pasa por largos períodos en los que prácticamente todo lo que hace es fusionar pequeñas páginas de memoria en páginas grandes.
Luego, ZFS ARC recupera las páginas después de que finaliza el proceso de uso de páginas grandes y se fragmentan.
Sospecho que puedes estar teniendo exactamente el mismo problema.
Para averiguarlo, corre
echo ::memstat | mdb -k
como root, en la zona global si está ejecutando zonas. Si tu memoria libre es muy baja, es posible que tengas este problema.
Para averiguarlo, ejecute el siguiente script dTrace, nuevamente como root desde la zona global para determinar dónde pasa el kernel todo su tiempo:
#!/usr/sbin/dtrace -s
profile:::profile-1001hz
/arg0/
{
@[ stack() ] = count();
}
Copie eso en un archivo, digamos hot.d, configúrelo como ejecutable ( chmod 755 hot.d) y ejecútelo como root desde la zona global:
./hot.d
Ejecútelo cuando experimente desaceleraciones. Déjelo funcionar durante unos buenos 10 a 20 segundos, si no más después de que emita matched 1 probe, luego rómpalo con CTRL-C. Luego emitirá unlotede producción, la mayoría de los cuales no te importan. Sin embargo, el último puñado de resultados de seguimiento de pila serán los más comunes muestreados, lo que le indicará dónde pasa el kernel todo su tiempo.
Eso definitivamente te dirá dónde está tu problema. Puede que no sea lo suficientemente preciso para resolverlo por completo y es posible que necesites investigar más, pero sabrás dónde buscar.
Si ve muchos rastros de pila dentro idleo waitdentro de ella, tiene un problema de espacio de usuario. Es posible que pueda identificarlo reemplazando stack()el script dTrace anterior con ustack()para obtener la pila de usuarios.
Y si ve muchos rastros de pila coalesceen los nombres de las funciones, el núcleo dedica todo su tiempo a crear páginas de memoria grandes. La solución para esto es liberar memoria, probablemente limitando el tamaño de ZFS ARC, tal vez incluso severamente. he tenido querótulael ZFS ARC en algunos servidores, hasta menos de 1 GB, para evitar que afecte al rendimiento.