Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Slurm programación basada en memoria
A partir de la versión 3.2.0, admite AWS ParallelCluster Slurm programación basada en memoria con el parámetro de configuración [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)cluster.
**nota**
[A partir de AWS ParallelCluster la versión 3.7.0, se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de instancias en Instances.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Para AWS ParallelCluster las versiones 3.2.0 a 3.6. *x*, no se `EnableMemoryBasedScheduling` puede habilitar si configuras varios tipos de [instancias en Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
**aviso**
Cuando especificas varios tipos de instancias en un Slurm coloque un recurso de cómputo en cola con la `EnableMemoryBasedScheduling` opción habilitada, el `RealMemory` valor es la cantidad mínima de memoria disponible para todos los tipos de instancias. Si especificas tipos de instancias con capacidades de memoria muy diferentes, esto podría provocar que se desperdicie una cantidad significativa de memoria.
Con`EnableMemoryBasedScheduling: true`, el Slurm el programador rastrea la cantidad de memoria que requiere cada trabajo en cada nodo. Luego, el Slurm el programador usa esta información para programar varios trabajos en el mismo nodo de cómputo. La cantidad total de memoria que requieren los trabajos en un nodo no puede ser mayor que la memoria de nodo disponible. El programador evita que un trabajo utilice más memoria de la que se solicitó cuando se envió el trabajo.
Con `EnableMemoryBasedScheduling: false`, los trabajos podrían competir por la memoria en un nodo compartido y provocar errores y `out-of-memory` eventos en los trabajos.
**aviso**
Slurm utiliza una notación de potencia de 2 para sus etiquetas, como MB o GB. Lea estas etiquetas como MiB y GiB, respectivamente.
## Slurm configuración y programación basada en memoria
Con, `EnableMemoryBasedScheduling: true` Slurm establece lo siguiente Slurm parámetros de configuración:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) en la `slurm.conf`. Esta opción configura la memoria del nodo para que sea un recurso consumible en Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)en el Slurm `cgroup.conf`. Con esta opción, el acceso de un trabajo a la memoria se limita a la cantidad de memoria que el trabajo solicitó cuando se envió.
**nota**
Varios otros Slurm los parámetros de configuración pueden afectar al comportamiento del Slurm programador y administrador de recursos cuando se configuran estas dos opciones. Para obtener más información, consulte la [.Slurm Documentación. ](https://slurm.schedmd.com/documentation.html)
## Slurm programador y programación basada en memoria
**`EnableMemoryBasedScheduling: false` (predeterminado)**
De forma predeterminada, `EnableMemoryBasedScheduling` se establece en "false". Si es falsa, Slurm no incluye la memoria como recurso en su algoritmo de programación y no rastrea la memoria que utilizan los trabajos. Los usuarios pueden especificar la `--mem MEM_PER_NODE` opción de establecer la cantidad mínima de memoria por nodo que requiere un trabajo. Esto obliga al programador a elegir nodos con un `RealMemory` valor de al menos `MEM_PER_NODE` al programar el trabajo.
Por ejemplo, supongamos que un usuario envía dos trabajos con `--mem=5GB`. Si los recursos solicitados, por ejemplo, GPUs están disponibles CPUs o están disponibles, los trabajos se pueden ejecutar al mismo tiempo en un nodo con 8 GiB de memoria. Los dos trabajos no están programados en nodos de procesamiento con menos de 5 GiB de `RealMemory`.
**aviso**
Cuando la programación basada en memoria está desactivada, Slurm no registra la cantidad de memoria que utilizan los trabajos. Los trabajos que se ejecutan en el mismo nodo pueden competir por los recursos de memoria y provocar que el otro trabajo falle.
Cuando la programación basada en memoria está deshabilitada, se recomienda a los usuarios que no especifiquen las opciones [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) o [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu). Estas opciones pueden provocar un comportamiento diferente al que se describe en la [Slurm Documentación](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Cuando `EnableMemoryBasedScheduling` se establece en verdadero, Slurm realiza un seguimiento del uso de memoria de cada trabajo y evita que los trabajos consuman más memoria de la solicitada con las opciones de `--mem` envío.
En el ejemplo anterior, un usuario envía dos trabajos con`--mem=5GB`. Los trabajos no se pueden ejecutar al mismo tiempo en un nodo con 8 GiB de memoria. Esto se debe a que la cantidad total de memoria necesaria es mayor que la memoria disponible en el nodo.
Con la programación basada en la memoria habilitada `--mem-per-cpu` y `--mem-per-gpu` compórtese de forma coherente con lo que se describe en la Slurm . Por ejemplo, un trabajo se envía con `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. En este caso, Slurm asigna al trabajo un total de 4 GiB para cada nodo.
**aviso**
Cuando la programación basada en memoria está habilitada, recomendamos que los usuarios incluyan una especificación `--mem` al enviar un trabajo. Con el valor predeterminado Slurm la configuración que se incluye AWS ParallelCluster, si no se incluye ninguna opción de memoria (`--mem`,`--mem-per-cpu`, o`--mem-per-gpu`), Slurm asigna toda la memoria de los nodos asignados a la tarea, incluso si solo solicita una parte de los demás recursos, como CPUs o GPUs. De esta forma, se evita que se compartan nodos hasta que finalice el trabajo, ya que no hay memoria disponible para otros trabajos. Esto sucede porque Slurm establece la memoria por nodo para el trabajo en caso de que no [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)se proporcionen especificaciones de memoria en el momento de enviar el trabajo. El valor predeterminado de este parámetro es 0 y especifica un acceso ilimitado a la memoria de un nodo.
Si hay varios tipos de recursos informáticos con diferentes cantidades de memoria disponibles en la misma cola, es posible que a un trabajo enviado sin opciones de memoria se le asignen diferentes cantidades de memoria en distintos nodos. Esto depende de los nodos que el programador ponga a disposición del trabajo. Los usuarios pueden definir un valor personalizado para las opciones, por ejemplo [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), `DefMemPerNode` o, a nivel de clúster o partición en el Slurm archivos de configuración para evitar este comportamiento.
## Slurm RealMemory y AWS ParallelCluster SchedulableMemory
Con el Slurm configuración que se suministra con AWS ParallelCluster, Slurm se interpreta [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)como la cantidad de memoria por nodo disponible para las tareas. A partir de la versión 3.2.0, de forma predeterminada, se AWS ParallelCluster establece `RealMemory` en el 95 por ciento de la memoria que aparece en [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types) y que devuelve la EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)de Amazon.
Cuando la programación basada en memoria está inhabilitada, Slurm el planificador se utiliza `RealMemory` para filtrar los nodos cuando los usuarios envían un trabajo con una especificación. `--mem`
Cuando la programación basada en memoria está habilitada, Slurm el planificador se interpreta como la cantidad máxima de memoria disponible `RealMemory` para los trabajos que se ejecutan en el nodo de cómputo.
Es posible que la configuración predeterminada no sea óptima para todos los tipos de instancias:
+ Esta configuración puede ser superior a la cantidad de memoria a la que realmente pueden acceder los nodos. Esto puede suceder cuando los nodos de cómputo son tipos de instancias pequeñas.
+ Esta configuración puede ser superior a la cantidad de memoria a la que realmente pueden acceder los nodos. Esto puede ocurrir cuando los nodos de cómputo son tipos de instancias grandes y puede generar una cantidad significativa de memoria no utilizada.
Puede usar [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)para ajustar el valor de `RealMemory` configurado por AWS ParallelCluster para los nodos de cómputo. Para anular el valor predeterminado, defina un valor personalizado específico para `SchedulableMemory` para la configuración de su clúster.
Para comprobar la memoria disponible real de un nodo de cómputo, ejecuta el `/opt/slurm/sbin/slurmd -C` comando en el nodo. Este comando devuelve la configuración de hardware del nodo, incluido el [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)valor. Para obtener más información, consulte [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Asegúrese de que los procesos del sistema operativo del nodo de cómputo tengan suficiente memoria. Para ello, limite la memoria disponible para los trabajos configurando el `SchedulableMemory` valor en un valor inferior al `RealMemory` valor devuelto por el comando `slurmd -C`.