## 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 `. 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](https://slurm.schedmd.com/priority_multifactor.html#config) 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: ```console sprio -j ``` Para múltiples jobs ```console sprio -j ,,... ``` Por ejemplo, para ver el job 123456: ```console 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.