Identificando la memoria física perdida

Tengo problemas con un servidor que se está quedando sin memoria física y tengo problemas para discernir si es del proceso Java de mi aplicación o de otra cosa en el servidor. Tomemos el siguiente escenario:

Memoria física del servidor: 3747 MB
Java -Xms64m
Java -Xmx512m
Java XX: MaxPermSize = 512m

Cuando inicio el servidor, el sistema operativo (RHEL) informa que se están utilizando 487 MB, utilizando su herramienta de informes de memoria favorita ( top, cat /proc/meminfo | grep Mem, free -m, etc.). Cuando comienzo mi proceso Java (pid 123), usa alrededor de 215 MB de memoria física (según lo informado por la memoria RES en ps -f -p 123), llevando mi memoria total usada a alrededor de 700 MB.

Si lo dejo correr durante un día entero, la memoria RES para mi proceso fluctúa un poco, pero generalmente es consistente. Sin embargo, la memoria total del servidor ha aumentado constantemente alrededor de 1500 MB, llevándola a un total de 2200 MB.

Si mi tamaño de almacenamiento dinámico de Java o el almacenamiento dinámico de generación permanente crecieran, ¿no se reflejaría en la memoria RES del proceso?

Además, parece que no puedo dar cuenta de esos 1500 MB adicionales en ninguna parte.

# ps aux | awk '{ RES+=$6 } END { printf("RES: %.2fMB\n", RES/1024) }'
RES: 722.23MB

¿Alguien puede ayudarme a encontrar ese recuerdo perdido? Básicamente estoy tratando de averiguar si este es mi problema con la aplicación, o el problema del equipo de infraestructura con la construcción de su servidor.

Linux usa la política de recuperación, pero no marca como "realmente libre" cualquier memoria utilizada recientemente (en la teoría de que restregarla cuesta esfuerzo, dejar las cosas por ahí en caso de que alguien la use nuevamente no cuesta nada y puede ahorrar un paquete). No se preocupe por los informes de "memoria libre". Mire cuánto (si lo hay) se está utilizando (el intercambio es esencialmente un espacio en disco para los requisitos de memoria que realmente desbordan la memoria física; el disco es extremadamente lento, no es necesario). Si le preocupa el rendimiento, instale y configure un software de monitoreo como el infame sar ( sysstat, seguramente hay un paquete para su sistema), registrará lo que está sucediendo en detalle para su posterior examen. Con dichos informes en mano, sabrá cuál es su cuello de botella (en todo caso). El comentario de que "la optimización prematura es la raíz de todo mal" se debe a que las personas son muy malas para adivinar dónde están los problemas reales de rendimiento y terminan "arreglando" algo que funciona perfectamente.