Esta semana me he topado con un problema en un cliente a la hora de lanzar numerosos procesos o aplicaciones de Spark. Todas ellas ejecutadas bajo modo YARN. La primera parte de dichas apps se ejecutaban y finalizaban para bien o para mal transcurrido un cierto tiempo, pero alcanzado un punto y sin saber el por qué, muchos de los nuevos trabajos que lanzaba finalizaban inmediatamente y de manera errónea. En un principio la única causa era la falta de recursos.
Esto no tenía lógica alguna, pues en caso de no haber recursos suficientes, los trabajos deberían quedarse en estado ACCEPTED y una vez el YARN fuera capaz de asignárselos pasar al estado RUNNING, vamos, quedar encolados, no morir directamente. Además, un simple top en los servidores o gracias a nuestra herramienta de monitorización demostraba la 'incoherencia' del mensaje.
Indagando más en los logs de la aplicación de Spark, para una mejor comprensión y visualización me apoyo en Livy, the REST Spark Server, llegué a observar el siguiente error: "java.io.ioexception couldn't set io streams". Ya tenía algo más de donde poder tirar.
Lo primero que hice fue revisar la configuración del usuario con el que se ejecutan los jobs o aplicaciones de Spark en cuanto a lo que respecta al uso o límites establecidos para el uso de recursos:
# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63238
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
¡Y voilà! En seguida algo llamó mi atención: max user processes (-u) 1024. Valor establecido demasiado bajo.
Traté de configurar dicho valor en "caliente", pero... quedó descartado:
# ulimit -u 65536
bash: ulimit: max user processes: no se puede modificar el límite: Operación no permitida
¡Ah! Y no aplica el intentarlo con sudo ;)
Tocaba pues, configurar los valores adecuados a través del fichero correspondiente. Bien, existen dos opciones:
1) /etc/security/limits.conf - Fichero de propiedades general.
2) /etc/security/limits.d/<userName>.conf - Fichero de propiedades relacionadas únicamente, o al menos debería ser así, con el usuario <userName>.
Básicamente estos ficheros sirven para controlar, limitar y/o repartir los recursos del sistema en caso de estar éste compartido entre diferentes usuarios y/o aplicaciones, evitando así que por ejemplo uno haga un uso excesivo de CPU viéndose perjudicado el resto de usuarios del sistema. Algo que en un entorno BigData con Hadoop y demás herramientas analíticas o de procesamiento, va a ser de lo más normal ;)
Si abrimos el primer fichero, veremos que se nos explica un poco la sintaxis del mismo.
...
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
...
# - nproc - max number of processes // para el caso que estamos tratando
...
Para un mejor entendimiento y/o administración o por una simple manía mía, soy partidario de la segunda opción.
Ahora bien, al trabajar sobre una plataforma con Cloudera, ya existía el fichero /etc/security/limits.d/cloudera-scm.conf por lo que para evitar tener que 'pensar' en los valores a establecer, decidí probar copiando dicha configuración a la del usuario correspondiente.
# sudo cp /etc/security/limits.d/clouderascm.conf /etc/security/limits.d/spark-user.conf
Sino, una configuración posible sería:
username soft nofile 32768
username soft nproc 65536
username hard nofile 1048576
username hard nproc unlimited
username hard memlock unlimited
username soft memlock unlimited
Por último, para que los cambios tuvieran efecto, fue necesario reiniciar la máquina.
Una vez hecho esto, el sistema permitió una mayor carga de trabajo y donde antes daba el error "java.io.ioexception couldn't set io streams" ahora los trabajos eran encolados, estado ACCEPTED.
0 comentarios:
Publicar un comentario