Estamos ejecutando RedHat 3.4.6(x32) en VMWareEsx3.5(x64) con 6 GB de RAM. Algunos procesos de Java (incluido jboss) se ejecutan en segundo plano.
El problema es que los procesos de Java consumen mucha memoria y, a veces, el OOM-killer los elimina. Cuando OOM-killer está a punto de actuar, la memoria física libre es muy baja, entre 100 MB y 200 MB, pero no se utiliza el intercambio (99% gratis). A veces esto también provoca pánico en el núcleo.
- Entonces, ¿por qué no se utiliza el swap?
- ¿Cómo investigar este pánico del núcleo?
- ¿Es prudente utilizar 6 GB de memoria en Redhat de 32 bits?
Gracias
Respuesta1
Personalmente, nunca usaría PAE (más de 4G de RAM en un sistema de 32 bits). Obtendrá un rendimiento mucho mayor ejecutando un kernel y un sistema reales de 64 bits.
OOM solo debería activarse cuando un malloc pueda fallar. (no cuando tienes muchos intercambios disponibles)
Es probable que el kernel de 32 bits sea parte de la causa. PAE utiliza diferentes zonas de memoria y es posible que a una zona no se le permita realizar malloc desde otra.
¿Has modificado tu swappiness? (Con qué facilidad el núcleo utilizará el intercambio). cat /proc/sys/vm/swappiness ?
También puedes investigar el ajuste de vm.dirty_ratio o vm.lower_zone_protection = 100.
¿Has captado el pánico del núcleo? (una consola serie suele ser una buena forma de hacer esto)
También puede intentar adelantarse al OOM-Killer con su propio software de monitoreo de procesos. (eche un vistazo a Monit)
Toda la suerte
Respuesta2
Las máquinas virtuales RHEL4 que ejecutan Oracle/Java eliminan procesos aleatoriamente mediante OOM Killer. Detalles OOM Killer elimina aplicaciones aunque ESX no esté bajo carga de memoria. El comando superior muestra que se está almacenando una gran cantidad de memoria en caché y apenas se utiliza el intercambio. Solución
Cuando el tamaño de los datos a copiar excede el tamaño de la memoria física, oom-killer comienza a eliminar procesos aleatoriamente.
Esto se puede solucionar ejecutando:
sysctl -w vm.protección_zona_inferior 100
Cuando lower_zone_protection se establece en 100, aumenta el umbral de páginas libres en 100, iniciando así la recuperación de páginas antes y evitando que NFS (Network File System) se quede muy por detrás de las demandas de memoria del kernel. Esto hace que la recuperación de páginas se realice antes, proporcionando así más "protección" para las zonas. Redhat identifica este problema en RHEL y han proporcionado una solución alternativa en los siguientes artículos: