Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Best practice
<a name="best-practices"></a>

## Best practice di Amazon EC2
<a name="best-practices-ec2"></a>

 Segui le attuali best practice di EC2 e assicurati una disponibilità sufficiente di storage dei dati. 

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

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

Lo scheduler Linux può riordinare i pacchetti su socket UDP se i processi corrispondenti non sono collegati a un core specifico. Qualsiasi thread che invia o riceve dati UDP deve collegarsi a un core specifico per tutta la durata della trasmissione dei dati.

## AWS Ground Station elenco di prefissi gestiti
<a name="managed-prefix-list-best-practice"></a>

Si consiglia di utilizzare l'elenco di prefissi `com.amazonaws.global.groundstation` gestito da AWS quando si specificano le regole di rete per consentire la comunicazione dall'antenna. Per ulteriori informazioni su [AWS Managed Prefix Lists, consulta Working with](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) AWS Managed Prefix Lists.

## Limitazione del contatto singolo
<a name="single-contact-limitation"></a>

 AWS Ground Station Agent supporta più flussi per contatto, ma supporta solo un contatto alla volta. Per evitare problemi di pianificazione, non condividere un'istanza tra più gruppi di endpoint di flussi di dati. Se una configurazione a singolo agente è associata a più DFEG diversi ARNs, non riuscirà a registrarsi. 

## Esecuzione di servizi e processi insieme all'agente AWS Ground Station
<a name="avoiding-contested-cores"></a>

 Quando si avviano servizi e processi sulla stessa istanza EC2 dell' AWS Ground Station agente, è importante associarli a v CPUs non utilizzati dall' AWS Ground Station agente e dal kernel Linux, poiché ciò può causare colli di bottiglia e persino la perdita di dati durante i contatti. Questo concetto di associazione a una v specifica è noto come affinità. CPUs 

Core da evitare:
+ `agentCpuCores`da [File di configurazione dell'agente](configuring-agent.md#agent-config-file)
+ `interrupt_core_list` da [Ottimizza le interruzioni hardware e le code di ricezione: influisce sulla CPU e sulla rete](ec2-instance-performance-tuning.md#tune-hardware-interrupts).
  + I valori predefiniti possono essere trovati da [Appendice: Parametri consigliati per l'accordatura interrupt/RPS](ec2-instance-performance-tuning.md#recommended-parameters)

### Ad esempio, utilizzando un'`c5.24xlarge`istanza
<a name="avoiding-contested-cores-example"></a>

Se hai specificato

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

e sono scappato

`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`

quindi evita i seguenti core:

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

### Servizi di affinitizzazione (systemd)
<a name="avoiding-contested-cores-with-services"></a>

 I servizi appena lanciati verranno automaticamente affinitizzati a quelli menzionati in precedenza. `interrupt_core_list` Se il caso d'uso dei servizi lanciati richiede core aggiuntivi o richiede core meno congestionati, segui questa sezione. 

Controlla a quale affinità è attualmente configurato il tuo servizio con il comando:

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

 Se vedi un valore vuoto come`CPUAffinity=`, significa che probabilmente utilizzerà i core predefiniti del comando precedente `...bin/set_irq_affinity.sh <using the cores here> ...` 

Per sovrascrivere e impostare un'affinità specifica, trova la posizione del file di servizio eseguendo:

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

 Apri e modifica il file (usando `vi``nano`, ecc.) e inseriscilo `CPUAffinity=<core list>` nella `[Service]` sezione come segue: 

```
[Unit]
...

[Service]
...
CPUAffinity=2,3

[Install]
...
```

Salva il file e riavvia il servizio per applicare l'affinità con: 

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

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

 Per maggiori informazioni visita: [Red Hat Enterprise Linux 8 - Gestione, monitoraggio e aggiornamento del kernel - Capitolo 27. Configurazione delle politiche 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) utilizzando systemd. 

### Affinitizzazione dei processi (script)
<a name="avoiding-contested-cores-with-processes"></a>

 Si consiglia vivamente di affinitizzare manualmente gli script e i processi appena lanciati, poiché il comportamento predefinito di Linux consentirà loro di utilizzare qualsiasi core della macchina. 

Per evitare conflitti di base per qualsiasi processo in esecuzione (come python, script bash, ecc.), avvia il processo con:

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

 Se il processo è già in esecuzione, usa comandi come `pidof``top`, o `ps` per trovare l'ID di processo (PID) del processo specifico. Con il PID puoi vedere l'attuale affinità con: 

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

 e puoi modificarlo con:

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

Per ulteriori informazioni su taskset, vedere [taskset - Linux man page](https://linux.die.net/man/1/taskset)