SGE - QSUB deja de enviar los trabajos en el modo -sync

Question

Tengo un script en Perl que prepara los archivos de entrada a un programa binario y se somete la ejecución del programa binario de la cola SGE versión del sistema 6.2u2.

Los trabajos se presentarán con la opción -sync y para permitir que el script de perl padres la capacidad de supervisar el estado de los trabajos enviados con la función waitpid.

Esto también es muy útil porque el envío de un SIGTERM al script Perl padres se propaga esta señal para cada uno de los niños, que luego hacia delante esta señal en qsub, por tanto, que terminan con gracia todos los trabajos enviados asociados.

Por lo tanto, es bastante crucial que yo sea capaz de enviar trabajos con esta opción -sync y.

Por desgracia, me siguen dando el siguiente error:

Unable to initialize environment because of error: range_list containes no elements

Aviso la ortografía incorrecta de containes ''. Eso es NO un error tipográfico. Simplemente muestra cuán mal mantenido debe estar esta área del código/mensaje de error.

Los envíos intentados que producen este error no pueden incluso generar los archivos STDOUT y STDERR *.e{JOBID} y *.o{JOBID}. La presentación simplemente falla por completo.

la búsqueda en Google para este mensaje de error sólo da lugar a mensajes no resueltos en Foro oscura.

Este error ni siquiera se produce de forma fiable. Puedo volver a ejecutar mi script y los mismos trabajos no necesariamente generarán el error. También parece no importar de qué nodo intento enviar trabajos.

Mi esperanza es que alguien aquí pueda resolver esto.

Las respuestas a cualquiera de estas preguntas por lo tanto resolver mi problema:

1. qué persiste este error en las versiones más recientes de SGE?
2. ¿Puedo modificar mis opciones de línea de comando para qsub para evitar esto?
3. ¿De qué diablos está hablando este mensaje de error?

Answer 1

Nuestro sitio solucionó este problema en SGE 6.2u5. He publicado algunas preguntas en la lista de correo, pero no había solución. Hasta ahora.

Resulta que el mensaje de error es falso. Descubrí esto leyendo los registros de cambios en el repositorio de Unipo Github "núcleo abierto". Más tarde vi el problema mencionado en las Notas de la versión de Son Of Gridengine v8.0.0c.

Estas son las confirmaciones relacionadas en el repositorio GitHub:

• https://github.com/gridengine/gridengine/commit/b449607972614e4608272d8c0fc6f109d35fbecc
• https://github.com/gridengine/gridengine/commit/a47c32f965111554ec076db1526a6ad62c5bdae5

Lo que el mensaje de error debería decir es que has alcanzado el límite del número de qsub sync -y trabajos en el sistema. Este parámetro se conoce como MAX_DYN_EC. El valor por defecto en nuestra versión fue de 99, y los cambios anteriores aumento que por defecto a 1000.

la definición de MAX_DYN_EC (desde la (página hombre sge_conf 5)) es:

Sets the max number of dynamic event clients (as used by qsub -sync y and by Grid Engine DRMAA API library sessions). The default is set to 99. The number of dynamic event clients should not be bigger than half of the number of file descriptors the system has. The number of file descriptors are shared among the connections to all exec hosts, all event clients, and file handles that the qmaster needs.

Puede comprobar cuántos clientes de eventos dinámicos que con el siguiente comando:

$ qconf -secl | grep qsub | wc -l 

Hemos añadido MAX_DYN_EC=1000-qmaster_params través qconf -mconf. He probado enviar cientos de trabajos de qsub -sync y y ya no alcanzamos el error range_list. Antes del cambio MAX_DYN_EC, hacerlo provocaría el error de manera confiable.

Answer 2

Encontré una solución a este problema, o al menos una solución.

Mi objetivo era conseguir que las instancias individuales de qsub permanecieran en primer plano, ya que el trabajo que enviaba todavía estaba en cola o en ejecución. Esto se logró con la opción -sync pero resultó en el error horriblemente impredecible que describo en mi pregunta.

La solución a este problema fue utilizar el comando qrsh con la opción now -n. Esto hace que el trabajo se comporte de manera similar a qsub -sync, ya que mi script puede monitorear implícitamente si un trabajo enviado se está ejecutando utilizando waitpid en la instancia de qrsh.

La única salvedad a esta solución es que la cola se está operando no debe hacer ninguna distinción entre los nodos interactivos (ofrecidos por qrsh) y nodos no interactivos (accesibles por qsub). Si existe una distinción (es probable que haya menos nodos interactivos que no interactivos), esta solución alternativa puede no ser de ayuda.

Sin embargo, como no he encontrado nada ni cerca de una solución al problema qsub -sync que sea tan funcional como esta, deje que esta publicación salga a través de las interwebs a cualquier alma rebelde atrapada en mi situación similar.