¿Has visto procesos de 6GB o más en prstat y pensaste que el servidor estaba sin memoria? En Solaris, ese diagnóstico suele ser incorrecto. Muchos administradores interpretan el RSS como consumo real, cuando en realidad gran parte corresponde a memoria compartida. La presión real de memoria se detecta desde el kernel, no desde la vista por proceso. Regla práctica Si pi y po están en cero y el sr es bajo, no existe presión de memoria. Antes de analizar procesos, analiza el sistema. Paso 1. Verificar si existe paging real Ejecutamos: Salida del servidor analizado: Observamos que: El sistema no está intercambiando memoria con swap ni realizando escaneo agresivo. No existe presión de memoria. Paso 2. Analizar la memoria desde el kernel Para obtener la distribución real de memoria física: Salida: La memoria anónima representa aproximadamente 84GB (21%), mientras que más de 230GB permanecen libres. El sistema se encuentra holgado desde el punto de vista de RAM. Paso 3. Por qué prstat puede resultar engañoso Muchos análisis comienzan aquí: Extracto: A simple vista puede parecer un consumo elevado. Sin embargo, Oracle utiliza memoria compartida (SGA). El RSS no representa consumo independiente por proceso. En un servidor con 384GB de RAM, 37GB utilizados por Oracle no representan presión. Errores comunes al analizar memoria en Solaris Checklist operativo Antes de escalar una incidencia por memoria, verifica: Si estas condiciones se cumplen, el problema no es RAM. Conclusión En el servidor analizado: No existe presión de memoria. Si el sistema presenta lentitud, la investigación debe centrarse en CPU, I/O o comportamiento de aplicación. Idea clave para recordar En Solaris, la memoria no se diagnostica desde prstat. Se diagnostica desde el kernel.