Consejos y buenas prácticas de uso

Uso del espacio temporal alta velocidad

El home de cada usuario se encuentra compartido a través de la red mediante NFS. Por esta razón toda escritura o lectura del contenido del home es considerablemente lenta. Sin embargo, todos los servidores de computo cuentan con discos de estado sólido para la lectura y escritura de información local al servidor. El tiempo de acceso a estos discos es sensiblemente menor que el tiempo de acceso al home. Para sacar provecho este espacio se encuentra disponible, en cada servidor, un directorio /scratch/<nombre_de_usuario> con 300 GB de capacidad.

Para utilizar el espacio disponible en /scratch de forma correcta es necesario reservar el espacio que se utilizará. Esto evita que el gestor coloque dos trabajos con fuerte uso de este recurso en la misma maquina. El espacio se puede reservar agregando la opción --tmp=xxxG donde xxx es la cantidad de GB a utilizar.

Se recomienda fuertemente hacer uso de /scratch/<nombre_de_usuario> para el almacenamiento de resultados parciales durante la ejecución de un trabajo. Luego, estos resultados pueden ser movidos al home una única vez al finalizar la ejecución. Al momento de usarlo es importante manejar idéntificadores únicos de archivos para evitar colisiones de nombres con otros usuarios (es posible crear directorios para simplificar este problema). Por último, solicitamos eliminar todos los archivos propios de /scratch/<nombre_de_usuario> luego de la finalización de un trabajo para mantener un uso razonable del espacio.

Optimización del uso de memoria

Para obtener información del uso de memoria de un trabajo ya terminado se sugiere utilizar el comando:

sacct -j <jobid> --format=User,Job,JobName,CPUTime,Elapsed,MaxRSS

Es recomendable que la cantidad máxima de memoria utilizada por un trabajo (MaxRSS) sea similar a la cantidad de memoria pedida para ese trabajo en el script SBATCH. Si la cantidad de memoria utilizada es mucho mayor que la pedida, entonces el trabajo terminará usando espacio de swap para ejecutar. Mientras que en la situación opuesta, si la cantidad de memoria utilizada es mucho menor que la pedida, el gestor SLURM podría postergar innecesariamente la ejecución de un trabajo por falta de recursos.