Slurm agendamento baseado em memória - AWS ParallelCluster

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 SlurmSettingsEnableMemoryBasedScheduling/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.

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.

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.

ComEnableMemoryBasedScheduling: 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

ComEnableMemoryBasedScheduling: true, Slurm define o seguinte Slurm parâmetros de configuração:

  • SelectTypeParameters=CR_CPU_Memory no slurm.conf. Essa opção configura a memória do nó para ser um recurso consumível no Slurm.

  • ConstrainRAMSpace=yesno 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.

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 --mem-per-cpu ou --mem-per-gpu. Essas opções podem causar um comportamento diferente do descrito no Slurm Documentação.

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 DefMemPerNodequando 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 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 RealMemorya 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 e retornada pela EC2 API DescribeInstanceTypesda 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/ComputeResources/SchedulableMemorypara 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 RealMemory. Para obter mais informações, consulte slurmd -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.