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á.

# Práticas recomendadas
<a name="best-practices"></a>

## Melhores práticas do Amazon EC2
<a name="best-practices-ec2"></a>

 Siga as melhores práticas atuais do EC2 e garanta disponibilidade suficiente de armazenamento de dados. 

[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)

## Agendador Linux
<a name="linux-scheduler"></a>

O agendador Linux pode reordenar pacotes em soquetes UDP se os processos correspondentes não estiverem fixados em um núcleo específico. Qualquer thread que envie ou receba dados UDP deve se fixar em um núcleo específico durante a transmissão de dados.

## AWS Ground Station lista de prefixos gerenciada
<a name="managed-prefix-list-best-practice"></a>

É recomendável utilizar a lista de prefixos `com.amazonaws.global.groundstation` gerenciada pela AWS ao especificar as regras de rede para permitir a comunicação da antena. Consulte [Trabalhar com as listas de prefixos gerenciados pela AWS](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) para obter mais informações sobre Listas de Prefixos Gerenciadas pela AWS.

## Limitação de contato único
<a name="single-contact-limitation"></a>

 O agente do AWS Ground Station oferece suporte a vários streams por contato, mas suporta apenas um único contato por vez. Para evitar problemas de agendamento, não compartilhe uma instância em vários grupos de endpoints de fluxo de dados. Se uma única configuração de agente estiver associada a vários DFEG diferentes ARNs, ela falhará no registro. 

## Executando serviços e processos junto com o AWS Ground Station agente
<a name="avoiding-contested-cores"></a>

 Ao iniciar serviços e processos na mesma instância EC2 do AWS Ground Station Agente, é importante vinculá-los a v que CPUs não estão em uso pelo AWS Ground Station Agente e pelo kernel Linux, pois isso pode causar gargalos e até mesmo perda de dados durante os contatos. Esse conceito de vinculação a v específico CPUs é conhecido como afinidade. 

Núcleos a serem evitados:
+ `agentCpuCores` de [Arquivo de configuração do agente](configuring-agent.md#agent-config-file).
+ `interrupt_core_list` do [Ajuste interrupções de hardware e filas de recebimento - afeta a CPU e a rede](ec2-instance-performance-tuning.md#tune-hardware-interrupts).
  + Os valores padrão podem ser encontrados em [Apêndice: Parâmetros recomendados para ajuste interrupt/RPS](ec2-instance-performance-tuning.md#recommended-parameters)

### Como exemplo, usando uma `c5.24xlarge` instância
<a name="avoiding-contested-cores-example"></a>

Se você especificou

`"agentCpuCores": [24,25,26,27,72,73,74,75]"`

e fugiu

`echo "@reboot sudo /opt/aws/groundstation/bin/set_irq_affinity.sh '0,1,48,49' 'ffffffff,ffffffff,ffffffff' >> /var/log/user-data.log 2>&1" >>/var/spool/cron/root`

em seguida, evite os seguintes núcleos:

`0,1,24,25,26,27,48,49,72,73,74,75`

### Serviços de afinização (systemd)
<a name="avoiding-contested-cores-with-services"></a>

 Os serviços recém-lançados serão automaticamente afinizados com os `interrupt_core_list` mencionados anteriormente. Se o caso de uso dos serviços lançados exigir núcleos adicionais ou precisar de núcleos menos congestionados, siga esta seção. 

Verifique para qual afinidade seu serviço está configurado atualmente com o comando:

```
systemctl show --property CPUAffinity <service name>
```

 Se você ver um valor vazio como`CPUAffinity=`, isso significa que ele provavelmente usará os núcleos padrão do comando acima `...bin/set_irq_affinity.sh <using the cores here> ...` 

Para substituir e definir uma afinidade específica, encontre a localização do arquivo de serviço executando:

```
systemctl show -p FragmentPath <service name>
```

 Abra e modifique o arquivo (usando `vi``nano`, etc.) e coloque o `CPUAffinity=<core list>` na `[Service]` seção como: 

```
[Unit]
...

[Service]
...
CPUAffinity=2,3

[Install]
...
```

Salve o arquivo e reinicie o serviço para aplicar a afinidade com: 

```
systemctl daemon-reload
systemctl restart <service name>

# Additionally confirm by re-running
systemctl show --property CPUAffinity <service name>
```

 Para obter mais informações, visite: [Red Hat Enterprise Linux 8 - Gerenciando, monitorando e atualizando o kernel - Capítulo 27. Configurando políticas de CPU Affinity e NUMA](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/assembly_configuring-cpu-affinity-and-numa-policies-using-systemd_managing-monitoring-and-updating-the-kernel) usando systemd. 

### Processos de afinização (scripts)
<a name="avoiding-contested-cores-with-processes"></a>

 É altamente recomendável que scripts e processos recém-lançados sejam afinizados manualmente, pois o comportamento padrão do Linux permitirá que eles usem qualquer núcleo na máquina. 

Para evitar conflitos fundamentais em qualquer processo em execução (como python, scripts bash etc.), inicie o processo com:

```
taskset -c <core list> <command>
# Example: taskset -c 8 ./bashScript.sh
```

 Se o processo já estiver em execução, use comandos como `pidof``top`, ou `ps` para encontrar a ID do processo (PID) do processo específico. Com o PID, você pode ver a afinidade atual com: 

```
taskset -p <pid>
```

 e pode modificá-lo com:

```
taskset -p <core mask> <pid>
# Example: taskset -p c 32392 (which sets it to cores 0xc -> 0b1100 -> cores 2,3)
```

Para obter mais informações sobre o conjunto de tarefas, consulte conjunto de [tarefas - página do manual Linux](https://linux.die.net/man/1/taskset)