Hola a todos,
Este es mi primer artículo en mi blog y quería escribir algo de utilidad y sobre algo que suele ocurrir con frecuencia.
Sobre este tema hay bastante documentación, pero siempre viene bien que haya algo escrito en español acerca de este tema.
El problema que suele ocurrir con Java en contenedores OpenVZ, suele ser algo así:
-bash-3.00# /usr/java/jre1.5.0_06/bin/java -version Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine.
Este error se produce porque los contenedores OpenVZ tienen una serie de restricciones a bajo nivel como pueden ser el número de páginas de memoria accesibles, máximo número de procesos o la visibilidad que tiene el contenedor de la swap. Pero nos puede pasar que miremos la memoria del contenedor y la tengamos prácticamente libre y pensemos: “pero si tengo un contenedor con 8Gb de memoria RAM y solo estoy usando 4Gb, ¿cómo es posible que falle?” Pues eso es por lo que comentaba al principio del párrafo, es por los límites de los recursos que controla OpenVZ. Hay que tener en cuenta que la memoria que se nos muestra en el contenedor al ejecutar “free -m” no es real, es la suma de la memoria física y la memoria swap que se le asigna a ese contenedor.
En concreto para Java el problema viene por el número de páginas de memoria accesibles y por la visibilidad de la swap.
Para ver si se están produciendo errores, por ejemplo en el número de páginas de memoria accesibles, podemos ejecutar este comando:
-bash-3.00# cat /proc/user_beancounters
Esto nos mostrará lo siguiente:
Version: 2.5
uid resource held maxheld barrier limit failcnt
104: kmemsize 3943800 4160542 9753527 9752512 0
lockedpages 0 0 32 32 0
privvmpages 23222 38193 69152 73575 2
shmpages 2441 3417 8192 8192 0
dummy 0 0 0 0 0
numproc 53 58 256 256 0
physpages 14000 16202 0 2147483647 0
vmguarpages 0 0 6144 2147483647 0
oomguarpages 14004 16202 6144 2147483647 0
numtcpsock 8 12 80 80 0
numflock 4 10 100 110 0
numpty 1 1 16 16 0
numsiginfo 0 3 256 256 0
tcpsndbuf 0 24508 319488 524288 0
tcprcvbuf 0 10116 319488 524288 0
othersockbuf 22280 27124 132096 336896 0
dgramrcvbuf 0 2228 132096 132096 0
numothersock 15 21 80 80 0
dcachesize 237062 270354 1048576 1097728 0
numfile 3239 3501 4086 4086 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 10 128 128 0
Para saber si se están produciendo errores nos tendremos que fijar en la columna de la derecha, si hay algún valor que no está a 0, eso quiere decir que se están produciendo errores en alguno de los recursos que controla OpenVZ. En este caso, podemos ver que se están produciendo errores en el número de páginas de memoria accesibles “privvmpages”; esto se produce porque ha llegado al límite.
En mi caso, para solucionar este problema he incrementado el límite de “privvmpages” y le he dado visibilidad a la memoria swap.
Para dar visibilidad a la memoria swap he utilizado este comando:
vzctl set 10006 --swappages 512M --save
Con esto, lo que hacemos es decirle a Proxmox que el contenedor 10006 vea 512 Mb de la memoria total como memoria swap.
Para aumentar el límite del número de páginas de memoria accesibles se puede utilizar este comando:
vzctl set 10006 --privvmpages 20000000:20100000 --save
Con esto, lo que hacemos es asignarle al contenedor 10006 el número máximo de “barrier”, que es la barrera superior, y de “limit”, que es el límite máximo de páginas de memoria. Estos valores hay que adecuarlos como cada uno estime oportuno y dependiendo de la memoria que tenga el contenedor. Hay que tener en cuenta que estos valores no pueden ser iguales, ya que esta diferencia entre los dos valores se utilizará para la asignación de memoria de “alta prioridad”; si no se configura un “limit” mayor que la “barrier”, cuando se llene no podrá reservar una parte de memoria para procesos prioritarios.
Otra cosa que tenemos que tener en cuenta es que si tenemos varios contenedores y la suma total de la memoria de todos los contenedores es superior a la memoria de la máquina anfitriona y además, a los contenedores les asignamos unos límites muy altos, esto puede dar muchos problemas de rendimiento.
Y para finalizar, mi experiencia ha sido que después de realizar esos dos cambios me ha funcionado todo perfecto. Este problema me surgió con una instalación de Zimbra separada en 3 contenedores diferentes y con otros dos contenedores donde tenía instalados varios tomcats con diferentes aplicaciones.
Espero que este artículo os sirva de ayuda y también espero vuestros comentarios. 
Saludos y hasta la próxima.