Changes between Version 4 and Version 5 of mem_slurm

Timestamp:

Jun 12, 2026, 9:40:54 AM (10 days ago)

Author:

i22balur

Comment:

--

mem_slurm

@@ -2 +2 @@
 El sistema de colas slurm no tiene el conocimiento apriorístico sobre las necesidades de los trabajos que lanzan los usuarios. En principio se "fia" de los parámetros que el usuario le especifica en su fichero respecto al consumo de recursos, ya sea de cores de cómputo o de memoria.
 
-De esa manera si un usuario especifica en su fichero slurm solamente el parámetro {{{#SBATCH --ntasks=2}}} asumiendo que su trabajo creará dos hilos de ejecución, al no haber especificado el parámetro '''--mem''' slurm entenderá que este trabajo necesita toda la memoria del nodo. De esa forma aunque el resto de cores del nodo estén ociosos, no podrá entrar en él ningún trabajo de otro usuario, ni siquiera del mismo que mandó el primer trabajo.
+De esa manera si un usuario especifica en su fichero slurm solamente el parámetro {{{#SBATCH --ntasks=2}}} asumiendo que su trabajo creará dos hilos de ejecución, al no haber especificado el parámetro '''--mem''' slurm reservará una cantidad de memoria predeterminada por el sistema.
 
 Sin embargo si el usuario sabe que su trabajo consumirá como mucho 10Gb de memoria, debe poner en su fichero slurm el parámetro {{{#SBATCH --mem=10gb}}}. Así permitirá que otros trabajos puedan entrar hasta que la suma de valores de memoria de todos los trabajos del nodo llegue al límite de la memoria del mismo, o hasta que todos los cores se ocupen.
 
-Es importante tener en cuenta que el parámetro '''--mem''' es una restricción laxa, esto es, si al final nuestro trabajo ocupara más memoria de la que fijamos, se ejecutará perfectamente siempre que el nodo tenga memoria disponible. 
+Es importante tener en cuenta que el parámetro '''--mem''' restringe la cantidad de memoria disponible por nuestros trabajos. De esta forma, si un proceso intenta usar más memoria de la reservada su ejecución podría verse afectada.
 
-Los administradores podemos poner valores por defecto por si no se especifica nada por parte del usuario, pero al no tener conocimiento de lo que se va a ejecutar es posible que hagamos más mal que bien.
+En el siguiente ejemplo se reserva 1000MB de memoria pero se utilizan 1500MB, lo que provoca que el OMM Killer (mecanismo del kernel de Linux) finalice el proceso:
+
+{{{#!bash
+[rbarbudo@admin01 ~]$ srun --mem 1000M -p fast stress --vm 1 --vm-bytes 1500M
+srun: job 914678 queued and waiting for resources
+srun: job 914678 has been allocated resources
+stress: info: [233475] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
+stress: FAIL: [233475] (415) <-- worker 233476 got signal 9
+stress: WARN: [233475] (417) now reaping child worker processes
+stress: FAIL: [233475] (451) failed run completed in 1s
+slurmstepd: error: Detected 1 oom-kill event(s) in StepId=914678.0 cgroup. Some of your processes may have been killed by the cgroup out-of-memory handler.
+srun: error: x440-21: task 0: Out Of Memory
+}}} 
+
+
+Con sacct podemos verificar que que el proceso no pudo finalizar correctamente ya que se quedó sin memoria:
+
+{{{#!bash
+[rbarbudo@admin01 ~]$ sacct -j 914678 --format=JobID,JobName,Partition,Account,AllocCPUs,State%15,ExitCode
+       JobID    JobName  Partition    Account  AllocCPUS           State ExitCode 
+------------ ---------- ---------- ---------- ---------- --------------- -------- 
+914678           stress       fast         si          2   OUT_OF_MEMORY    0:125 
+}}}