Cola de trabajos

Mi trabajo tarda mucho tiempo en entrar ¿qué puedo hacer?

1. Para que el backfiller de Slurm pueda asignar recursos correctamente es fundalmental usar la flag --time en el script de envío. Si hay nodos ociosos en estado planned para un job grande que todavía no puede ingresar, el backfiller va a llenar ese tiempo con jobs de duración menor al tiempo de espera del job grande. Al no especificar la flag --time, Slurm asume que el job va a tardar el máximo de la partición (48hs en las colas de producción) y acomoda los recursos en base a esa asunción.

2. Los jobs muy pequeños (<1 nodo) tienen menos prioridad, por lo que en general van a tardar más tiempo en empezar a correr. En lo posible se debería tratar de escalar el cómputo lo más posible para garantizar un mejor uso de los recursos. Por ejemplo, un job que usa solamente 16 cores a la vez podría escalar a 64 cores (un nodo entero) o «empaquetar» múltiples jobs en uno solo si esto no es posible. Si el sistema físico/input del job lo permite, es deseable usar más nodos por menos tiempo.

3. Si estuviste haciendo un uso intensivo del cluster en el último mes, es posible que tu valor de fairshare sea muy bajo. Podés verificar tus valores de fairshare para todos los proyectos en los que estés usando el comando sshare -a | grep <usuario>. El valor de fairshare va de 0 a 1, siendo cero la peor prioridad posible para quienes dieron mucho uso al cluster. El valor del fairshare es una consecuencia natural de consumir muchos recursos de cómputo, y vuelve a un valor positivo con una vida media de dos semanas, i.e. ~1 mes en total.

Si necesitás hacer pruebas inmediatamente (menos de 20 minutos) podés hacer uso de la partición testing de forma interactiva (o en batch).

¿Qué determina la prioridad de ejecución de los jobs?

La prioridad de ejecución de los jobs está determinado por tres factores:

1. El tamaño del job. Los jobs más grandes tienen mayor prioridad, porque se asume que hacen un mejor uso de recursos y mejoran el rendimiento del cluster en términos de ciclos de procesador en uso. Monitoreamos la performance de los jobs para corregir los casos en los que no están correctamente escalados.

2. El tiempo de espera en cola. Los jobs que hace más tiempo esperan en cola tienen más prioridad para que no queden infinitamente esperando si tienen menor prioridad en los otros factores. Esto se compone con el factor anterior: si dos jobs tienen el mismo tiempo de espera y el job A usa más recursos que el job B, el job A tiene mayor prioridad.

3. El valor de fairshare. Los jobs con mayor fairshare tienen mayor prioridad, porque se asume que quienes más usaron el cluster recientemente tienen una necesidad de cómputo menos acuciante que quienes no pudieron dar uso recientemente. El valor de fairshare se restaura luego de ~1 mes.

Adicionalmente, el backfiller acomoda los jobs que considera que pueden entrar en «huecos libres» del scheduler, priorizando las características del job por sobre su prioridad absoulta.

¿Cómo veo la prioridad de mis jobs?

Para ver la prioridad de un único job:

sprio -j <jobid> 

Para múltiples jobs

sprio -j <jobid1>,<jobid2>,...

Por ejemplo, para ver el job 123456:

sprio -j 123456
          JOBID PARTITION   PRIORITY       SITE        AGE  FAIRSHARE    JOBSIZE
         123456 cpunode           16          0         14          2          1

Esto indica los valores que Slurm está tomando para el tiempo de espera (AGE), el tamaño del job (JOBSIZE) y fairshare (FAIRSHARE). El valor resultante (PRIORITY) determina cuándo va a correrse. Un valor cercano a 0 es muy bajo, mientras que un valor superior a 100 es bastante alto. Un job que tiene mucha prioridad en general va a tardar menos tiempo en entrar y uno con poca prioridad más. El caso de jobs muy grandes puede ser una excepción porque requiere que el scheduler reserve el espacio necesario, y esto puede demorarse de acuerdo a la demanda del cluster.