As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Slurm agendamento baseado em memória
A partir da versão 3.2.0, suporta AWS ParallelCluster Slurm agendamento baseado em memória com o parâmetro de configuração [`SlurmSettings`[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/cluster.
**nota**
[A partir da AWS ParallelCluster versão 3.7.0, `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em Instâncias.](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
Para AWS ParallelCluster as versões 3.2.0 a 3.6. *x*, não `EnableMemoryBasedScheduling` pode ser ativado se você configurar vários tipos de instância em [Instâncias](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
**Atenção**
Quando você especifica vários tipos de instâncias em um Slurm recurso de computação de fila com `EnableMemoryBasedScheduling` ativado, o `RealMemory` valor é a quantidade mínima de memória disponibilizada para todos os tipos de instância. Isso pode resultar em quantidades significativas de memória não utilizada se você especificar tipos de instância com capacidades de memória muito diferentes.
Com`EnableMemoryBasedScheduling: true`, o Slurm O agendador rastreia a quantidade de memória que cada trabalho exige em cada nó. Então, o Slurm O agendador usa essas informações para agendar vários trabalhos no mesmo nó de computação. A quantidade total de memória que os trabalhos exigem em um nó não pode ser maior do que a memória disponível do nó. O programador impede que um trabalho use mais memória do que a solicitada quando o trabalho foi enviado.
Com `EnableMemoryBasedScheduling: false`, os trabalhos podem competir pela memória em um nó compartilhado e causar falhas no trabalho e eventos `out-of-memory`.
**Atenção**
Slurm usa uma notação de potência de 2 para seus rótulos, como MB ou GB. Leia esses rótulos como MiB e GiB, respectivamente.
## Slurm configuração e agendamento baseado em memória
Com`EnableMemoryBasedScheduling: true`, Slurm define o seguinte Slurm parâmetros de configuração:
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) no `slurm.conf`. Essa opção configura a memória do nó para ser um recurso consumível no Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)no Slurm `cgroup.conf`. Com essa opção, o acesso de um trabalho à memória é limitado à quantidade de memória que o trabalho solicitou quando enviado.
**nota**
Vários outros Slurm os parâmetros de configuração podem afetar o comportamento do Slurm agendador e gerenciador de recursos quando essas duas opções são definidas. Para obter mais informações, consulte o [.Slurm Documentação](https://slurm.schedmd.com/documentation.html).
## Slurm agendador e agendamento baseado em memória
**`EnableMemoryBasedScheduling: false` (padrão)**
Por padrão, `EnableMemoryBasedScheduling` é definido como falso. Quando falso, Slurm não inclui memória como recurso em seu algoritmo de agendamento e não rastreia a memória que os trabalhos usam. Os usuários podem especificar a opção `--mem MEM_PER_NODE` para definir a quantidade mínima de memória por nó que um trabalho exige. Isso força o programador a escolher nós com um valor `RealMemory` de pelo menos `MEM_PER_NODE` ao agendar o trabalho.
Por exemplo, suponha que um usuário envie dois trabalhos com `--mem=5GB`. Se os recursos solicitados, como CPUs ou GPUs estiverem disponíveis, os trabalhos poderão ser executados ao mesmo tempo em um nó com 8 GiB de memória. As duas tarefas não estão programadas em nós de computação com menos de 5 GiB de `RealMemory`.
**Atenção**
Quando o agendamento baseado em memória está desativado, Slurm não rastreia a quantidade de memória que os trabalhos usam. Os trabalhos executados no mesmo nó podem competir por recursos de memória e fazer com que o outro trabalho falhe.
Quando a programação baseada em memória está desativada, recomendamos que os usuários não especifiquem as opções [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) ou [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu). Essas opções podem causar um comportamento diferente do descrito no [Slurm Documentação](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Quando `EnableMemoryBasedScheduling` está definido como verdadeiro, Slurm rastreia o uso da memória de cada trabalho e impede que os trabalhos usem mais memória do que a solicitada com as opções de `--mem` envio.
Usando o exemplo anterior, um usuário envia dois trabalhos com `--mem=5GB`. Os trabalhos não podem ser executados ao mesmo tempo em um nó com 8 GiB de memória. Isso ocorre porque a quantidade total de memória necessária é maior do que a memória disponível no nó.
Com o agendamento baseado em memória ativado `--mem-per-cpu` e `--mem-per-gpu` se comporte de forma consistente com o que está descrito no Slurm documentação. Por exemplo, um trabalho é enviado com `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. Nesse caso, Slurm atribui ao trabalho um total de 4 GiB para cada nó.
**Atenção**
Quando a programação baseada em memória está ativada, recomendamos que os usuários incluam uma especificação `--mem` ao enviar um trabalho. Com o padrão Slurm configuração incluída com AWS ParallelCluster, se nenhuma opção de memória estiver incluída (`--mem`,`--mem-per-cpu`, ou`--mem-per-gpu`), Slurm atribui toda a memória dos nós alocados ao trabalho, mesmo que ele solicite somente uma parte dos outros recursos, como CPUs ou. GPUs Isso evita efetivamente o compartilhamento de nós até que o trabalho seja concluído, pois não há memória disponível para outros trabalhos. Isso acontece porque Slurm define a memória por nó da tarefa para [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)quando nenhuma especificação de memória for fornecida no momento do envio da tarefa. O valor padrão para esse parâmetro é 0 e especifica o acesso ilimitado à memória de um nó.
Se vários tipos de recursos de computação com quantidades diferentes de memória estiverem disponíveis na mesma fila, um trabalho enviado sem opções de memória poderá receber quantidades diferentes de memória em nós diferentes. Isso depende de quais nós o programador disponibiliza para o trabalho. Os usuários podem definir um valor personalizado para opções, como `DefMemPerNode` ou [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), no nível do cluster ou da partição no Slurm arquivos de configuração para evitar esse comportamento.
## Slurm RealMemory and AWS ParallelCluster SchedulableMemory
do Slurm configuração que é fornecida com AWS ParallelCluster, Slurm interpreta como [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)a quantidade de memória por nó disponível para trabalhos. A partir da versão 3.2.0, por padrão, é AWS ParallelCluster definida `RealMemory` como 95% da memória listada nos [tipos de EC2 instância da Amazon](https://aws.amazon.com/ec2/instance-types) e retornada pela EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)da Amazon.
Quando o agendamento baseado em memória é desativado, o Slurm O agendador usa `RealMemory` para filtrar os nós quando os usuários enviam um trabalho com o `--mem` especificado.
Quando o agendamento baseado em memória está ativado, o Slurm O agendador interpreta como `RealMemory` a quantidade máxima de memória disponível para trabalhos em execução no nó de computação.
A configuração padrão pode não ser ideal para todos os tipos de instância:
+ Essa configuração pode ser maior do que a quantidade de memória que os nós podem realmente acessar. Isso pode acontecer quando os nós de computação são tipos de instâncias pequenas.
+ Essa configuração pode ser maior do que a quantidade de memória que os nós podem realmente acessar. Isso pode acontecer quando os nós de computação são tipos de instância grandes e podem levar a uma quantidade significativa de memória não utilizada.
Você pode 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 o valor de `RealMemory` configure by AWS ParallelCluster para nós de computação. Para substituir o padrão, defina um valor personalizado para `SchedulableMemory` especificamente para sua configuração de cluster.
Para verificar a memória real disponível de um nó de computação, execute o comando `/opt/slurm/sbin/slurmd -C` no nó. Esse comando retorna a configuração de hardware do nó, incluindo o valor [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory). Para obter mais informações, consulte [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Certifique-se de que os processos do sistema operacional do nó de computação tenham memória suficiente. Para fazer isso, limite a memória disponível para trabalhos definindo o valor de `SchedulableMemory` como menor do que o valor de `RealMemory` retornado pelo comando `slurmd -C`.