En esta entrada vamos a ver como instalar, configurar, ejecutar y monitorizar un proceso java. Es algo realmente importante saber que consumo de recursos está realizando nuestra aplicación java sobre todo cuando se trata de servidores de aplicaciones (JBoss, Weblogic, Tomcat, OAS…) o como en mi caso, aplicaciones del ecosistema BigData (flume, kafka, HBase, HDFS, Spark…).
Instalar JDK
Lo primero que tienen en común todas las aplicaciones anteriormente nombradas es que utilizan java para desplegarse, por lo que un requisito es tener la JDK (Java SE Development Kit) instalada. Por ello vamos a descargarla, instalarla y setear la variable JAVA_HOME.
- Descargar (yo personalmente siempre opto por la versión tar.gz):
- La desempaquetamos por ejemplo en /opt:
$ cd /opt $ sudo tar -xvf jdk-8u66-linux-x64.tar.gz
- Como en ocasiones se instalan varias versiones, a mi me gusta crear un enlace simbólico para que a la hora de setear la variable JAVA_HOME en el archivo de entorno del usuario o cualquiera de las aplicaciones no tengamos que especificar la ruta completa a cada uno de los distintos home de java :
$ sudo ln -s /opt/jdk1.8.0_66 java
Nota: Si cambio de jdk solo modifico el enlace pero no los archivos de configuración
- Por ejemplo ahora que vamos a setear la variable y el PATH en el archivo de configuración de perfil del usuario (bashrc, .profile o .bash_profile, según la distribución):
$ vi ~/.bashrc JAVA_HOME="/opt/java" export PATH="$PATH:$JAVA_HOME/bin"
- Salimos de la sesión y volvemos a entrar para que se exporte la variable al entorno y podamos comprobar que todo está ok:
$ java -version
IMPORTANTE: En ocasiones tenemos seteado el programa java en /etc/alternatives el cual apunta a la versión openjdk y cuando comprobamos la versión que acabamos de descargar no corresponde con la que muestra el comando:
$ ls -l /etc/alternatives |grep java java -> /usr/lib/jvm/java-7-openjdk-amd64
En este caso, recomiendo mover el java a javaold (por ejemplo) y crear un nuevo enlace a java -> /opt/java
Ejecutar proceso java
Bueno aunque en la mayoría de los casos todas las aplicaciones mencionadas al inicio ejecutan automáticamente su proceso a través de java, debemos de saber algunas cosillas. Por ejemplo para lanzar una aplicación java bastaría con:
$ java [-opciones] clase [argumentos]
Las opciones son las propias del comando java como por ejemplo definir un classpath (-cp) o mostrar la versión y continuar (-showversion), mientras que los argumentos son las opciones que acepta nuestra aplicación (archivo jar). Es aquí donde se le pasan los típicos parámetros de memoria (-Xmx, -Xms, etc…) y otros como -Dcom.sun.management.jmxremote con el que activamos el servicio jmx (que veremos en el siguiente post).
En la mayoría de las aplicaciones (si no en todas) existe un archivo de configuración del entorno java donde se pueden setear estos valores de forma permanente. Por ejemplo en mi caso, estoy trabajando con HBase (una BBDD NoSQL) y su archivo es $HBASE_HOME/conf/hbase-env.sh
Nota: Los parámetros pasados por línea de comandos en momento de ejecución sobre-escriben a los seteados en el archivo de configuración del entorno java.
Comprobando la ejecución del proceso
Si ya tenemos lanzada la aplicación en nuestro servidor, podremos comprobar los parámetros con la que esta ha sido lanzada:
$ ps -ef |grep java
Nota: Aquí vemos que la aplicación se lanzó con un heap max size (-Xmx) de 1GB entre otras propiedades.
Conectando con el proceso java (JVM)
Bueno ahora llega lo mejor, supongamos que queremos monitorizar este proceso para ver el consumo de memoria, como trabaja el recolector de basura (GC, Garbage Collector), uso de la CPU, etc… Para esto utilizaremos la herramienta Jconsole que viene con la JDK previamente instalada.
Si queremos ejecutar jconsole en un entorno donde no tenemos disponible un servidor de X (muy común en servidores de producción), tenemos dos opciones, o bien redireccionar la salida a nuestro equipo de escritorio o configurar un conector JMX RMI para usar la Jconsole de nuestro equipo de escritorio y conectar en remoto con el proceso java (esto lo veremos en el siguiente post).
Vamos a suponer que e nuestro caso queremos ejecutar la jconsole que se encuentra en la JDK del servidor en producción y que además este NO tiene un servidor de X
Configurar el reeenvío de X en el servidor
Lo primero es activar el reenvío de X en el servidor (donde se está ejecutando la aplicación java):
$ ssh mi_usuario@mi_servidor $ sudo vi /etc/ssh/sshd_config ## Añadimos al final del fichero X11Forwarding yes X11UseLocalhost no $ sudo service ssh restart
Ahora quizás nos haga falta tener los siguientes paquetes instalados:
$ sudo apt-get install libxtst6 $ sudo apt-get install libxrender1 $ sudo apt-get install libxi6
Ejecutando Jconsole
Ahora lo primero que haremos será conectarnos al servidor donde corre la jvm a través de ssh con la opción -X (habilita el X11 forwarding)
$ ssh -X mi_usuario@mi_servidor
Y ejecutamos jconsole tal que así:
$ jconsole <pid>
Nota: Si no conocemos el pid del proceso al que queremos conectar podemos verlo con el comando jps -m o ps -ef |grep java. También podemos omitir el pid y la consola se abrirá con todos los procesos java que se encuentran corriendo en el servidor y entre ellos seleccionaremos el nuestro.
Para monitorizar un proceso java, el usuario con el que conectamos debe de ser el mismo que el que lanzó la aplicación
IMPORTANTE: La herramienta Jconsole consume sus propios recursos, por lo que en muchos casos se prefiere que esta sea ejecutada en un equipo remoto, es decir, no en el servidor donde se ejecuta la aplicación java si no por ejemplo en nuestro equipo cliente. No confundamos que aunque estemos accediendo en remoto con nuestro equipo cliente, al final lo que hacemos es ejecutar Jconsole en el propio servidor y reenviar los gráficos a nuestro equipo cliente.
Ahora veremos como en nuestro equipo cliente nos aparece la consola tal que así:
Nota: En este caso hemos abierto jconsole sin indicar el pid es por ello que nos aparecen todos los procesos
En la siguiente entrada (2/3) veremos como activar el servicio JMX Remote para poder ejecutar la herramienta jconsole en un equipo cliente u otro cualquiera diferente al servidor donde se está ejecutando el proceso java, y conectar con este para monitorizarlo sin que esto impacte en el rendimiento del sistema.
#4sysadmins 