Laboratório de Processamento Paralelo e Distribuído (LPPD)
Índice
1. Apresentação
O LPPD - Laboratório de Processamento Paralelo e Distribuído, parte do Grupo de Processamento Paralelo e Distribuído e vinculado ao Instituto de Informática da UFRGS, mantém o Parque Computacional de Alto Desempenho (PCAD), uma infraestrutura voltada principalmente à pesquisa, desenvolvimento, ensino e extensão da comunidade científica. Trata-se de uma infraestrutura computacional utilizada por inúmeros grupos de pesquisa em computação e áreas correlatadas. Ele consiste em um conjunto de nós computacionais (servidores) interligados e que podem ser utilizados conjuntamente para a execução de aplicações paralelas de maior porte. O acesso aos recursos é realizado de forma remota por meio de um portal que organiza as solicitações de uso com base nos tipos de projetos aos quais os usuários estão vinculados. Como medida de segurança, nenhum usuário possui acesso físico à sala do Data Center onde os equipamentos estão instalados, no próprio Instituto de Informática.
2. Características técnicas
O PCAD possui um nó computacional físico que serve como portal, que pode ser visto como o front-end que centraliza os logins de usuários e permite a alocação de recursos. No front-end estão centralizados também o /home de cada usuário. Os recursos que podem ser alocados a partir do front-end são representados por um conjunto de nós computacionais para execução de aplicações paralelas. Cada nó computacional possui armazenamento local temporário. Estas características são detalhadas a seguir.
2.1. Detalhamento técnico
O PCAD possui mais de 1.000 núcleos de CPU e 100.000 de GPU (CUDA threads), distribuídos em mais de 40 nós computacionais. Pode-se compreender um nó como sendo um conjunto de processamento com configurações específicas. Por exemplo, cada nó possui uma determinada quantidade de um processador específico, uma quantidade específica de memória RAM por processador, uma GPU específica, agrupados no que chamamos de rack. Desse modo, temos diferentes nós de computação que apresentam diferentes características e configurações. O usuário pode escolher entre os diversos nós de acordo com sua necessidade específica. Por exemplo, para executar uma aplicação de IA, o usuário escolheria o nó hype, devido à presença de uma GPU NVIDIA Tesla K80, enquanto que para uma aplicação que execute exclusivamente em CPU, pode-se fazer uso de um nó sem GPU.
As partições representam a forma como esses nós estão organizados. Como pode-se ter mais de um nó com as mesmas características, dizemos que os nós que possuem as mesmas características fazem parte de uma partição. Como exemplo temos os 7 nós draco, que são 7 máquinas com as mesmas características agrupados sob a partição draco.
Os nós existentes no PCAD são detalhados a seguir:
| Nome | Partição | CPU | RAM | Acelerador | Disco | Placa-mãe |
|---|---|---|---|---|---|---|
| gppd-hpc[-,-2] | - | 2 x Intel(R) Xeon(R) E5-2630, 2.3 GHz, 24 threads, 12 cores | 32 GB DDR3 | - | 73.4T HDD | Dell Inc. 0H5J4J |
| bali2 | bali | 2 x Intel(R) Xeon(R) E5-2650, 2.0 GHz, 32 threads, 16 cores | 32 GB DDR3 | - | 931.5G HDD | Silicon Graphics International X9DRG-HF |
| beagle | beagle | 2 x Intel(R) Xeon(R) E5-2650, 2.0 GHz, 32 threads, 16 cores | 32 GB DDR3 | 2 x NVIDIA GeForce GTX 1080 Ti 11 GB | 931.0G HDD | Dell Inc. |
| blaise | blaise | 2 x Intel(R) Xeon(R) E5-2699 v4, 2.2 GHz, 88 threads, 44 cores | 256 GB DDR4 | 4 x Tesla P100 16 GB | 1.8T HDD,1.9T SSD | Supermicro X10DGQ |
| cei[1,2,3,4,5,6] | cei | 2 x Intel(R) Xeon(R) Silver 4116, 2.1 GHz, 48 threads, 24 cores | 96 GB DDR4 | - | 21.8T HDD,894.3G SSD | Supermicro X11DPU |
| cidia | cidia | 2 x Intel(R) Xeon(R) Silver 4208, 2.1 GHz, 32 threads, 16 cores | 320 GB DDR4 | 2 x NVIDIA GeForce RTX 2080 Ti 11 GB | 7.3T HDD,1.7T SSD | Supermicro X11DAi-N |
| draco7 | draco | 2 x Intel(R) Xeon(R) E5-2640 v2, 2.0 GHz, 32 threads, 16 cores | 128 GB DDR3 | - | 931.0G HDD | Dell Inc. 0KR8W3 |
| draco[1,2,5,6] | draco | 2 x Intel(R) Xeon(R) E5-2640 v2, 2.0 GHz, 32 threads, 16 cores | 64 GB DDR3 | Tesla K20m 4 GB | 1.8T HDD | Dell Inc. 0KR8W3 |
| draco[3,4] | draco | 2 x Intel(R) Xeon(R) E5-2640 v2, 2.0 GHz, 32 threads, 16 cores | 64 GB DDR3 | Tesla K20m 4 GB | 931.0G HDD | Dell Inc. 0KR8W3 |
| grace[1,2] | grace | 2 x Grace A02, 3.4 GHz, 144 threads, 144 cores | 480 GB LPDDR5 | NVIDIA L40S 46 GB | 4.4T NVME | Supermicro G1SMH |
| hype1 | hype | 2 x Intel(R) Xeon(R) E5-2650 v3, 2.3 GHz, 40 threads, 20 cores | 128 GB DDR4 | - | 558.9G HDD | HP ProLiant DL380 Gen9 |
| hype[2,3] | hype | 2 x Intel(R) Xeon(R) E5-2650 v3, 2.3 GHz, 40 threads, 20 cores | 128 GB DDR4 | - | 558.9G HDD | HP ProLiant XL170r Gen9 |
| hype5 | hype | 2 x Intel(R) Xeon(R) E5-2650 v3, 2.3 GHz, 40 threads, 20 cores | 128 GB DDR4 | 2 x Tesla K80 12 GB | 558.9G HDD | HP ProLiant XL190r Gen9 |
| knl[1,2,3,4] | knl | Intel(R) Xeon Phi(TM) 7250, 1.4 GHz, 68 threads, 68 cores | 112 GB DDR4 | - | 447.1G SSD | Intel Corporation S7200AP |
| lunaris | lunaris | AMD Ryzen Threadripper PRO 5965WX 24-Cores, 3.8 GHz, 48 threads, 24 cores | 256 GB DDR4 | 2 x Navi 31 [Radeon RX 7900 XT/7900 XTX] 21 GB | 1.9T NVME | ASUSTeK COMPUTER INC. Pro WS WRX80E-SAGE SE WIFI |
| phoenix | phoenix | 2 x Intel(R) Xeon(R) Gold 5317, 3.0 GHz, 48 threads, 24 cores | 128 GB DDR4 | - | 223.6G SSD | Supermicro X12DPL-NT6 |
| poti[1,2,3,4,5] | poti | Intel(R) Core(TM) i7-14700KF, 3.4 GHz, 28 threads, 20 cores | 96 GB DDR5 | NVIDIA GeForce RTX 4070 12 GB | 119.2G NVME,1.7T SSD | Gigabyte Technology Co., Ltd. Z790 UD AX |
| saude | saude | Intel(R) Xeon(R) E5-2620 v4, 2.1 GHz, 16 threads, 8 cores | 131 GB DDR4 | 3 x NVIDIA GeForce GTX 1080 Ti 11 GB | 7.3T HDD | ASUSTeK COMPUTER INC. X99-E-10G WS |
| sirius | sirius | AMD Ryzen 9 3950X 16-Core Processor, 3.5 GHz, 32 threads, 16 cores | 64 GB DDR4 | Navi 31 [Radeon RX 7900 XT/7900 XTX] 21 GB | 1.8T HDD,223.6G NVME,894.3G SSD | Gigabyte Technology Co., Ltd. X570 AORUS PRO |
| tsubasa | tsubasa | 2 x Intel(R) Xeon(R) Gold 6226, 2.7 GHz, 48 threads, 24 cores | 196 GB DDR4 | - | 1.8T SSD | Supermicro X11DGQ |
| tupi[3,4] | tupi | Intel(R) Core(TM) i9-14900KF, 3.2 GHz, 32 threads, 24 cores | 128 GB DDR5 | NVIDIA GeForce RTX 4090 24 GB | 1.8T NVME | Gigabyte Technology Co., Ltd. Z790 UD AX |
| tupi[5,6] | tupi | Intel(R) Core(TM) i9-14900KF, 3.2 GHz, 32 threads, 24 cores | 128 GB DDR5 | NVIDIA GeForce RTX 4090 24 GB | 1.8T NVME,1.7T SSD | Gigabyte Technology Co., Ltd. Z790 UD AX |
| tupi2 | tupi | Intel(R) Xeon(R) E5-2620 v4, 2.1 GHz, 16 threads, 8 cores | 224 GB DDR4 | NVIDIA GeForce RTX 4090 24 GB | 3.6T HDD,1.1T SSD | ASUSTeK COMPUTER INC. X99-DELUXE II |
| tupi1 | tupi | Intel(R) Xeon(R) E5-2620 v4, 2.1 GHz, 16 threads, 8 cores | 256 GB DDR4 | NVIDIA GeForce RTX 4090 24 GB | 2.2T SSD | ASUSTeK COMPUTER INC. X99-A II |
| turing | turing | 4 x Intel(R) Xeon(R) X7550, 2.0 GHz, 64 threads, 32 cores | 128 GB DDR3 | 4 x NEC TSUBASA Vector Engine Type 10BE SX-Aurora 48 GB | 4.5T HDD | Dell Inc. 0JRJM9 |
- Partições com máquinas de projetos que requerem permissão do coordenador do projeto
- apolo, tsubasa, cidia, blaise, saude, grace
2.2. Armazenamento
Os arquivos de cada usuário estão armazenados no front-end e são
acessados pelos nós de computação através de Network File System
(NFS). De maneira transparente, o NFS monta os dados do usuário na
partição que foi alocada e o usuário acessa os dados como se eles
estivessem armazenados localmente. Assim, o diretório $HOME de cada
usuário é acessível a partir de cada nó de computação.
Usuários podem executar aplicações que leem e escrevem dados
diretamente na sua $HOME, ou seja, no front-end. No entanto, essas
operações serão feitas pela rede, o que as torna lentas, visto que o
diretório $HOME é um Sistema de Arquivos de Rede (NFS - Network File
Sytem). O ideal, portanto, é utilizar o diretório $SCRATCH, que está
sempre montado em um disco local do nó computacional.
O $SCRATCH é um diretório temporário presente em cada nó de computação
e montado no sistema de arquivos próprio do nó. Cada usuário possui um
diretório dentro do scratch (/scratch/USERNAME). A variável de
ambiente $SCRATCH é configurada automaticamente no momento do
login. Desse modo, para acessar seu diretório scratch, basta acessar
$SCRATCH:
cd $SCRATCH
Antes da execução da aplicação, o usuário pode copiar os dados do seu
$HOME no NFS para o seu scratch, acessando as variáveis $HOME e
$SCRATCH:
cp $HOME/<diretório_origem> $SCRATCH/<diretório_destino>
No entanto, os dados são mantidos temporariamente no scratch do nó e
não podem ser acessados diretamente por outros nós de
computação. Desse modo, o usuário precisa copiar os dados para o seu
diretório $HOME ao final da execução do job:
cp $SCRATCH/<diretório_origem> $HOME/<diretório_destino>
IMPORTANTE: os arquivos presentes no scratch são temporários e podem
ser removidos a qualquer momento sem aviso prévio aos
usuários. Por isso se sugere que, assim que um job termine sua
execução, os dados relevantes sejam transferidos para a área de
armazenamento do $HOME.
SUPER IMPORTANTE: os dados na $HOME e no $SCRATCH não possuem backup
sendo o usuário o responsável por manter seus backups fora do
PCAD. Usuários podem copiar seus arquivos de e para o PCAD usando o
comando scp do ssh, ou ainda o rsync sobre ssh, sendo este o
recomendado.
Da máquina pessoal para o PCAD (a partir da máquina pessoal):
rsync --verbose --progress --recursive <diretório_origem> <usuario_no_pcad>@gppd-hpc.inf.ufrgs.br:~/<diretório_destino>
Do PCAD para a máquina pessoal (a partir da máquina pessoal):
rsync --verbose --progress --recursive <usuario_no_pcad>@gppd-hpc.inf.ufrgs.br:~/<diretório_origem> <diretório_destino>
Do PCAD para a máquina pessoal (a partir do PCAD):
rsync --verbose --progress --recursive <diretório_origem> <usuario_na_sua_maquina>@<maquina_pessoal>:~/<diretório_destino>
3. Conta, acesso e submissão
3.1. Solicitação de Conta no PCAD
O PCAD é uma infraestrutura experimental, com o propósito de servir de base para a realização de experimentos computacionais de apoio a pesquisa em computação e áreas afins. O formulário cuja URL encontra-se abaixo serve para solicitar a abertura de uma conta nesta plataforma.
Os pedidos recebidos são avaliados conjuntamente com o professor da UFRGS responsável indicado no formulário. Portanto, entre em contato primeiro com este professor antes de solicitar a conta.
3.2. Acesso e Submissão
O sistema operacional do PCAD é o Debian, sendo que o mesmo é acessado
por meio de SSH através do host gppd-hpc.inf.ufrgs.br. O comando para
acessá-lo a partir do terminal é o seguinte:
ssh <usuario_no_pcad>@gppd-hpc.inf.ufrgs.br
A submissão dos jobs deve ser feita através do gerenciador de recursos e filas Slurm, detalhado a seguir.
4. Gerenciador de filas
O gerenciador de filas utilizado é o Slurm. Todos os jobs devem ser submetidos através do Slurm. Utilize os comandos sinfo e sin para listar informações sobre as filas, partições e nós. Utilize o comando squeue para listar informações sobre os jobs e o escalonamento.
- As filas de execução (partições) do Slurm são:
- shared: beagle, bali2, draco[1-7], turing
- beagle: beagle
- blaise: blaise
- cei: cei[1-6]
- cidia: cidia
- draco: draco[1-7]
- bali: bali2
- hype: hype[1-5]
- saude: saude
- sirius: sirius
- tsubasa: tsubasa
- tupi: tupi[1-6]
- turing: turing
- grace: grace[1-2]
- poti: poti[1-5]
- lunaris: lunaris
Na maior parte das filas, o tempo máximo de alocação é de 24h. A fila shared permite o uso parcial do nó, compartilhando o uso com outros usuários. Priorize esta fila para realizar testes iniciais nos seus scrips de experimentos. As filas cei, cidia, greencloud, saude e tsubasa são exclusivas de projetos.
Deve-se ter o cuidado para ajustar corretamente o tempo de duração do job de acordo com as necessidades, para que o nó não fique alocado sem uso ou seja cancelado por ultrapassar o limite de tempo de execução. Priorize o uso de Jobs Não-Interativos (sbatch) na plataforma, pois o recurso computacional é liberado no momento que seu experimento terminar.
5. Submissão de Jobs
5.1. Jobs Não-Interativos (sbatch)
Jobs não interativos são aqueles onde o usuário submete um script que
realiza o experimento nas máquinas. O slurm permite esse tipo de
script utilizando diretivas em linhas que começam com #SBATCH. Todas
as linhas que começam com esta diretiva terão seu conteúdo passado
diretamente para o slurm no momento da alocação. O exemplo 1 abaixo
aloca um nó (--nodes=1) para 16 tarefas (--ntasks=16) na partição
draco (--partition=draco) por 2 horas (--time=02:00:00). Recomenda-se
o uso de parâmetros --output e --error de forma que a saída padrão e
de erro sejam direcionadas para arquivos, permitindo o debug do
job. No caso de exemplo, esses arquivos serão o nome do job (%x, no
caso o nome do arquivo que contém o script) e o seu ID (%j). As linhas
que não contém a diretiva do sbatch serão executadas normalmente.
5.1.1. Exemplo 1
No exemplo abaixo, o comando hostname é executado.
#!/bin/bash #SBATCH --job-name=exemplo1 #SBATCH --partition=draco #SBATCH --nodes=1 #SBATCH --ntasks=16 #SBATCH --time=02:00:00 #SBATCH --output=%x_%j.out #SBATCH --error=%x_%j.err hostname
Assumindo que o conteúdo acima está em um arquivo draco.slurm, basta
submeter o job da seguinte maneira na portal:
sbatch draco.slurm
5.1.2. Exemplo 2
No exemplo abaixo, um aplicação é executada em 7 nós da partição draco.
#!/bin/bash #SBATCH --job-name=exemplo2 #SBATCH --partition=draco #SBATCH --nodes=7 #SBATCH --ntasks=224 #SBATCH --time=6:00:00 #SBATCH --output=%x_%j.out #SBATCH --error=%x_%j.err mpicc exemplo2.c MACHINEFILE="nodes.$SLURM_JOB_ID" srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE mpirun --mca btl ^openib --mca btl_tcp_if_include eno1 --bind-to none -np $SLURM_NTASKS -machinefile $MACHINEFILE ./a.out
Assumindo que o conteúdo acima está em um arquivo draco_multi.slurm, basta
submeter o job da seguinte maneira na portal:
sbatch draco_multi.slurm
5.1.3. Exemplo 3
No exemplo abaixo, um aplicação é executada em 2 nós da partição hype.
#!/bin/bash #SBATCH --job-name=exemplo3 #SBATCH --partition=hype #SBATCH --nodes=2 #SBATCH --ntasks=80 #SBATCH --time=2:00:00 #SBATCH --output=%x_%j.out #SBATCH --error=%x_%j.err mpicc exemplo3.c MACHINEFILE="nodes.$SLURM_JOB_ID" srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE mpirun --mca oob_tcp_if_include 192.168.30.0/24 --mca btl_tcp_if_include 192.168.30.0/24 --mca btl_base_warn_component_unused 0 --bind-to none -np $SLURM_NTASKS -machinefile $MACHINEFILE ./a.out
Assumindo que o conteúdo acima está em um arquivo hype.slurm, basta
submeter o job da seguinte maneira na portal:
sbatch hype.slurm
5.2. Jobs Interativos (salloc)
Evite o uso de jobs interativos para aumentar a disponibilidade dos recursos para a comunidade.
Para submeter jobs interativos, é necessário utilizar o comando salloc, solicitando os recursos a serem utilizados. Quando o salloc consegue alocar os recursos solicitados para o job, ele informa ao usuário, o qual pode acessar o nó (via ssh), realizar as suas tarefas localmente e executar a aplicação.
5.2.1. Exemplo 1
Solicita a alocação de qualquer nó da partição draco por 5h.
salloc -p draco -J NOME-JOB-EX1 -t 05:00:00
5.2.2. Exemplo 2
Solicita a alocação da draco6 por 36h.
salloc -p draco -w draco6 -J NOME-JOB-EX2 -t 36:00:00
5.2.3. Exemplo 3
Solicita a alocação de dois nós da partição hype por 24h.
salloc -p hype -N 2 -J NOME-JOB-EX3 -t 24:00:00
5.2.4. Exemplo 4
Solicita a alocação de 6 núcleos da partição shared por 1h. O uso do nó é compartilhado com outros usuários, entretanto, os núcleos solicitados são dedicados.
salloc -p shared -c 6 -J NOME-JOB-EX4 -t 1:00:00
5.3. Jobs com múltiplos nós não-interativos (sbatch)
Uma forma muito frequente de uso de um cluster de computadores é o
emprego de múltiplas máquinas (nós) para executar a mesma aplicação
com emprego de MPI. Assumindo um programa MPI simples do tipo "Olá
Mundo" com o seguinte conteúdo no arquivo olamundo.c:
#include <mpi.h> #include <stdio.h> #include <unistd.h> int main(int argc, char **argv) { int rank; char hostname[256]; MPI_Init(&argc,&argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); gethostname(hostname,255); printf("Olá Mundo! Eu sou [%d] executando em [%s].\n", rank, hostname); MPI_Finalize(); return 0; }
Compile-o com mpicc:
mpicc olamundo.c -o olamundo
Construa um script slurm chamado multi-no.slurm com o conteúdo
abaixo. Serão alocados 5 nós com 80 tarefas na partição draco por 2
horas. O primeiro comando srun criará um arquivo de máquinas para a
execução do programa MPI. Cada linha desta arquivo conterá o nome do
nó onde será executada a aplicação MPI; como existem múltiplos cores,
o nome do nó será repetido várias vezes.
#!/bin/bash #SBATCH --job-name=exemplo #SBATCH --partition=draco #SBATCH --nodes=5 #SBATCH --ntasks=80 #SBATCH --time=2:00:00 #SBATCH --output=%x_%j.out #SBATCH --error=%x_%j.err MACHINEFILE="nodes.$SLURM_JOB_ID" srun -l hostname | sort -n | awk '{print $2}' > $MACHINEFILE mpirun -np $SLURM_NTASKS \ -machinefile $MACHINEFILE \ --mca btl ^openib \ --mca btl_tcp_if_include eno2 \ --bind-to none -np $SLURM_NTASKS \ ./olamundo
Assumindo que o programa olamundo foi compilado na $HOME do usuário e
que o script abaixo se encontra no mesmo local, basta submeter o job
da maneira habitual:
sbatch multi-no.slurm
5.4. Jobs multi-partição não-interativo (sbatch)
O slurm permite a criação de jobs multi-partição, para o caso onde o
usuário deseja usar nós heterogêneos de partições diferentes. A
documentação do slurm sobre jobs heterogêneos apresenta um
detalhamento bastante rico sobre o assunto. Abaixo apresentamos um
exemplo simples para a aplicação do tipo "Olá Mundo!", compilada no
binário olamundo.
Crie um arquivo multi-particao.slurm com o conteúdo
abaixo. Solicitaremos nós de três partições (5 nós da hype, cada um
com 20 tarefas; 5 nós da draco, cada um com 16 tarefas, e o único nó
da partição turing, com 32 tarefas). A diretiva packjob deve ser
obrigatoriamente empregada para separar os comandos de alocação para
cada partição. Como o programa MPI precisa de um arquivo de máquinas
de todo o conjunto, incluímos a função shell gen_machinefile que
imprime as nós alocados de uma partição de acordo com a quantidade de
tarefas alocadas naquele nó. Essa função é chamada para cada uma das
partições que foram alocadas, e toda a saída é direcionada para o
arquivo de máquinas (variável MACHINEFILE)
#SBATCH --time=02:00:00 #SBATCH --output=%x_%j.out #SBATCH --error=%x_%j.err #SBATCH --nodes=5 --partition=hype --ntasks=20 #SBATCH packjob #SBATCH --nodes=5 --partition=draco --ntasks=16 #SBATCH packjob #SBATCH --nodes=1 --partition=turing --ntasks=32 # Função para gerar um arquivo de máquina para uma partição function gen_machinefile { SLM_NODES=$1 SLM_TASKS=$2 if [ -z "$SLM_NODES" ]; then return fi for host in $(scontrol show hostname $SLM_NODES); do for machine in $(seq 1 $SLM_TASKS); do echo $host done done } # Três partições foram alocadas, portanto três chamadas a gen_machinefile MACHINEFILE="nodes.$SLURM_JOB_ID" gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_0 $SLURM_NPROCS_PACK_GROUP_0 > $MACHINEFILE gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_1 $SLURM_NPROCS_PACK_GROUP_1 >> $MACHINEFILE gen_machinefile $SLURM_JOB_NODELIST_PACK_GROUP_2 $SLURM_NPROCS_PACK_GROUP_2 >> $MACHINEFILE # Definir a quantidade de máquinas baseado no arquivo SLM_NTASKS=$(wc -l $MACHINEFILE | awk '{ print $1 }') # Executar a aplicação mpirun -np $SLM_NTASKS \ -machinefile $MACHINEFILE \ --mca oob_tcp_if_include 192.168.30.0/24 \ --mca btl_tcp_if_include 192.168.30.0/24 \ --mca btl_base_warn_component_unused 0 \ --bind-to none \ ./olamundo
5.5. Remover jobs da fila ou em execução
Pelo número do job
scancel NUMERO-DO-JOB
Todos jobs do usuário
scancel -u NOME-DO-USUARIO
6. Comandos especiais e administrativos
Algumas propriedades das máquinas podem ser alteradas pelo usuário sem permissões administrativas, e são resetadas no inicio de cada alocação.
6.1. Controle de CPU
A frequência e governor podem ser visualizados e alterados por
qualquer usuário utilizando os comandos cpufreq-info e cpufreq-set
respectivamente.
6.1.1. Exemplo 1
No exemplo abaixo, é definido a frequência máxima
do hardware para todos os cores de uma máquina, além do governor
performance.
for i in $(seq 0 $(( $(nproc) - 1 ))); do maxf=$(cat /sys/devices/system/cpu/cpu$i/cpufreq/cpuinfo_max_freq) cpufreq-set -c $i -g performance -d $maxf -u $maxf done
O turbobost pode ser alterado editando diretamente o arquivo:
/sys/devices/system/cpu/cpufreq/boost.
6.2. Configurações do Kernel
O Numa balancing pode ser ativado ou desativado utilizando os comandos (com sudo):
sudo /sbin/sysctl kernel.numa_balancing=1 sudo /sbin/sysctl kernel.numa_balancing=0
6.3. Frequência GPU
A frequência da GPU (MEM, GRAPHICS) pode ser configurada utilizando o comando:
gpu_control 715 1480
Esta é a saída do comando acima na máquina blaise.
Executing command [nvidia-smi -ac 715,1480] Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:05:00.0 Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:06:00.0 Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:84:00.0 Applications clocks set to "(MEM 715, SM 1480)" for GPU 00000000:85:00.0 All done.
7. Gerenciadores de pacotes
7.1. Guix
O PCAD possui o gerenciador de pacotes Guix como uma alternativa para a instalação de software. O manual completo pode ser encontrado em Guix Manual.
7.1.1. Configuração inicial
Para gerar um primeiro perfil (profile) para a utilização do guix, deve-se rodar o seguinte comando:
guix pull
O comando guix pull também atualiza a versão do Guix e pacotes para a última disponível. O processo pode ser demorado.
Para verificar a versão do Guix e quais canais estão disponíveis:
guix describe
Esse é um exemplo de saída do comando acima com o canal guix-hpc incluso:
Generation 5 Jul 07 2025 12:58:18 (current) guix-hpc c3db6d0 repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git branch: master commit: c3db6d05fbf91ea2cca965c568be2d98e4c92b07 guix a102022 repository URL: https://git.guix.gnu.org/guix.git branch: master commit: a102022c1b37b06bde140f24fa4e9b3f2cd9c68d
Para ativar outros canais, é recomendado olhar a seção Adicionando canais Guix.
7.1.2. Instalação de pacotes
É recomendada a utilização do comando guix shell em detrimento do comando guix install para a instalação de pacotes, já que o guix install adiciona por padrão os softwares instalados no seu $PATH, o que pode causar conflitos com softwares de sistema.
Abaixo segue um exemplo de comando para a utilização do OpenMPI na versão 5.0.7 utilizando guix shell:
guix shell openmpi@5.0.7 -- mpirun --version
E sua respectiva saída:
mpirun (Open MPI) 5.0.7 Report bugs to https://www.open-mpi.org/community/help/
É possível criar um manifest para guardar as configurações dos pacotes definidos com o comando abaixo:
guix shell --export-manifest openmpi@5.0.7 > manifest.scm
Para utilizar o manifest para carregar o ambiente:
guix shell -m manifest.scm -- mpirun --version
Veja mais sobre a utilização de manifests em Guix Writing Manifests.
Para criar um container isolado contendo apenas os pacotes selecionados, pode ser passada a opção --container:
guix shell --container openmpi
O comando acima criará um shell interativo onde apenas o OpenMPI estará disponível.
7.1.3. Adicionando canais Guix
Para adicionar novos canais no Guix, basta adicioná-los em ~/.config/guix/channels.scm e executar guix pull. Abaixo, segue a demonstração do trecho a ser adicionado para ativação do canal guix-hpc-non-free:
(cons (channel
(name 'guix-hpc-non-free)
(url "https://gitlab.inria.fr/guix-hpc/guix-hpc-non-free.git"))
%default-channels)
8. Referenciando o PCAD
8.1. Citação global
Todos os trabalhos que apresentarem resultados no qual utilizarem recursos do PCAD, devem fazer menção aos projetos individuais das máquinas ou referenciar o PCAD. Sugerimos a seguinte mensagem:
Alguns experimentos deste trabalho utilizaram os recursos da infraestrutura PCAD, http://gppd-hpc.inf.ufrgs.br, no INF/UFRGS.
Em inglês:
Some experiments in this work used the PCAD infrastructure, http://gppd-hpc.inf.ufrgs.br, at INF/UFRGS.
8.2. Citação de fomento específico
Os projetos individuais estão referenciados na tabela abaixo:
| Nome | Órgão de Fomento | Número do projeto de Pesquisa | Docente |
|---|---|---|---|
| grace[1-2] | FAPERGS | 22/2551-0000390-7 | Carla Maria Dal Sasso Freitas |
| cidia | FAPERGS | 20/2551-0000254-3 | João Luiz Dihl Comba |
| tupi[3-6] | Petrobras | TC 5900.0111175.19.9, 2020/00182-5 | Lucas Mello Schnorr |
| lunaris | Petrobras | TC 5900.0111175.19.9, 2020/00182-5 | Lucas Mello Schnorr, Philippe O. A. Navaux |
| tupi[1-2] | FAPERGS | 16/2551-0000348-8 | Lucas Mello Schnorr |
| bali2 | FAPERGS | 16/2551-0000488-9 | Lisandro Zambenedetti Granville |
| blaise | Petrobras | TC 0050.0102253.16.9 | Philippe O. A. Navaux |
| tsubasa | Petrobras | TC 0050.0102253.16.9 | Philippe O. A. Navaux |
| draco | INFRA FINEP - UFRGS | Philippe O. A. Navaux | |
| cei | SDECT/RS INCUBADORAS | Edital 02/2016 | Luciana Nedel |
| saude | Viviane P. Moreira | ||
| hype | HPE | Philippe O. A. Navaux |
9. Equipe e Contato
Coordenador do PCAD: Prof. Lucas Mello Schnorr.
Os membros atuantes com contribuições extremamente importantes:
- Cristiano Alex Künas (Doutorando) [2022 - ] - cakunas@inf.ufrgs.br
- Otho Marcondes (Mestrando) [2025- ] - otho.marcondes@inf.ufrgs.br
- Thiago Araujo (Doutorando) [2025- ] - thiago.araujo@inf.ufrgs.br
Ex-membros atuantes com contribuições extremamente importantes:
- Lucas Nesi (Pós-Doutorando) [2018-2024] - lucas.nesi@inf.ufrgs.br
- Matheus Serpa (Doutorando) [2018-2022] - msserpa@inf.ufrgs.br
Os usuários podem solicitar ajuda para problemas ou apresentar demandas de instalação/configuração através da lista de difusão (lembrando que o cadastro do e-mail do usuário ocorre no momento da criação da sua conta):
hpc-users-l@inf.ufrgs.br