- Parámetros por defecto para un qsub:
Se meten en el archivo $SGE_ROOT/default/common/sge_request
- Documentación scripts JSV:
http://linux.die.net/man/1/jsv (man jsv)
http://linux.die.net/man/3/jsv_script_interface (man jsv_script_interface)
- Variables de entorno en un script de SGE
El tema de las variables de entorno dentro de un script que se lanza al sistema de colas, es un poco confuso. Por defecto, cuando se hace un qsub, éste no pasa sus actuales variables de entorno al script que se está mandando a la cola, pero si el script es un bash, las va a cargar de todas formas cuando el script lo ejecute el SGE (el script leerá del profile o de donde proceda). Pero si este script es de python, el tema cambia. Por ejemplo:
[bash]user@server# cat mik.py
#!/usr/bin/python
import os
os.system(‘echo $PATH’)
user@server:# qsub mik.py
user@server:# cat mik.py.o271625
/scratch/sge/tmp/271625.1.normal.q:/usr/local/bin:/bin:/usr/bin[/bash]
Para solucionar este problema, se pueden usar los parámetros -V o -v de qsub, que sirven para exportar las variables de entorno al contexto de ejecución del script. Con -V exportamos todas las variables, y con -v sólo las que digamos. Yo uso esta última opción, para exportar sólo las variables que necesito:
[bash]user@server:~# qsub -v PATH mik.py
user@server:~# cat mik.py.o271625
/scratch/sge/tmp/271625.1.fast.q:/usr/local/bin:/bin:/usr/bin
user@server:# cat mik.py.o271627
/scratch/sge/tmp/271627.1.fast.q:/apps/sge/x86_64/6.2/bin/lx24-amd64:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/opt/jre1.5.0_12/bin[/bash]
- shell_start_mode
En una instalación reciente de pruebas de SGE, me encontré con que no podía hacer un qsub de un script de python:
line 3: import: command not found
line 5: syntax error near unexpected token `"echo $PATH"'
line 5: `os.system("echo $PATH")'
Estaba claro que lo que pasaba es que no estaba pillando la primera línea del script (el shebang) y era bash el que interpretaba el script.
Hay que cambiar el parámetro shell_start_mode de la cola, que por defecto está en posix_compliant (y omite la primera línea del script) a unix_behavior. Lo cambiamos con qconf -mq queueName
- qres.py: https://github.com/jhcepas/sge-tweaks/blob/master/qres Interesante utilidad para mostrar el estado del cluster
- export MALLOC_CHECK_=0
Es muy importante poner este export en /etc/profile por ejemplo. Hay un bug reportado que hace que el qsub, qstat o lo que sea, bajo ciertas condiciones falle con un «glib detected…». Me pasaba también que cuando un script de python hacía una llamada qstat, me cascaba, y con este export se solucionó:
[bash]#!/usr/bin/python
import os
os.system(«qstat -u ‘*'»)[/bash]
el qsub hay que hacerlo así:
[bash]qsub -v PATH,MALLOC_CHECK_ script.py[/bash]
- Prioridad de jobs: si tenemos la cola llena de jobs y tenemos a la espera unos cuantos y queremos insertar un job y que se ponga primero en la lista de espera, le podemos indicar prioridad máxima: qsub -p 1024 <job>
Autenticación SGE
Es interesante la característica de evitar que sge cree un usuario de sge cada vez que alguien hace un qsub (como hace por defecto) para restringir quién puede usar el cluster o no, o darle acceso a una determinada cola/recursos.
Con esto evitamos los qusb anónimos
qconf -mconf
pasar enforce_user de auto a true
Creamos una lista de acceso (ACL)
qconf -mu myACL name myACL type ACL fshare 0 oticket 0 entries user1,user2,user3
qconf -rattr queue xuser_lists myACL queue1.q qconf -rattr queue xuser_lists myACL queue2.q qconf -rattr queue user_lists myACL forced.q
De esta forma conseguimos que los usuarios user1, user2 y user3 no puedan entrar ni en la cola queue1.q ni queue2.q, y que solo puedan entrar en forced.q, así podemos definir los recursos que queramos en la cola forced.q y que esos usuarios no puedan consumir más.
Para dar de alta un nuevo usuario:
qconf -auser
Para añadirlo a la ACL:
qconf -au username myACL
Para borrarlo de la ACL:
qconf -du username myACL
Más comandos
- Deshabilitar todas las colas de un nodo, por ejemplo para realizar tareas de mantenimiento:
qmod -d *@node
Usar -e para volver a habilitar