Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Bonnes pratiques
## Bonnes pratiques relatives à Amazon EC2
Suivez les meilleures pratiques actuelles de l'EC2 et garantissez une disponibilité suffisante du stockage des données.
[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
## Planificateur Linux
Le planificateur Linux peut réorganiser les paquets sur les sockets UDP si les processus correspondants ne sont pas liés à un cœur spécifique. Tout thread qui envoie ou reçoit des données UDP doit s'associer à un noyau spécifique pendant toute la durée de la transmission des données.
## AWS Ground Station liste de préfixes gérée
Il est recommandé d'utiliser la liste de préfixes `com.amazonaws.global.groundstation` gérée par AWS lorsque vous spécifiez les règles du réseau pour autoriser les communications depuis l'antenne. Consultez la section [Utilisation des listes de préfixes gérées par AWS pour plus d'informations sur les listes](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) de préfixes gérées par AWS.
## Limitation du contact unique
L'agent AWS Ground Station prend en charge plusieurs flux par contact, mais ne prend en charge qu'un seul contact à la fois. Pour éviter les problèmes de planification, ne partagez pas une instance entre plusieurs groupes de points de terminaison de flux de données. Si une configuration d'agent unique est associée à plusieurs DFEG différents ARNs, son enregistrement échouera.
## Exécution de services et de processus en parallèle avec l' AWS Ground Station agent
Lorsque vous lancez des services et des processus sur la même instance EC2 que l' AWS Ground Station agent, il est important de les lier à v CPUs non utilisé par l' AWS Ground Station agent et le noyau Linux, car cela peut entraîner des blocages et même des pertes de données lors des contacts. Ce concept de liaison à un v spécifique CPUs est connu sous le nom d'affinité.
Noyaux à éviter :
+ `agentCpuCores`à partir de [Fichier de configuration de l'agent](configuring-agent.md#agent-config-file)
+ `interrupt_core_list` depuis [Réglez les interruptions matérielles et les files d'attente de réception, ce qui a un impact sur le processeur et le réseau](ec2-instance-performance-tuning.md#tune-hardware-interrupts).
+ Les valeurs par défaut peuvent être trouvées dans [Annexe : Paramètres recommandés pour le interrupt/RPS réglage](ec2-instance-performance-tuning.md#recommended-parameters)
### À titre d'exemple, en utilisant une `c5.24xlarge` instance
Si vous avez spécifié
`"agentCpuCores": [24,25,26,27,72,73,74,75]"`
et a couru
`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`
puis évitez les noyaux suivants :
`0,1,24,25,26,27,48,49,72,73,74,75`
### Services d'affinisation (systemd)
Les services nouvellement lancés s'affineront automatiquement aux services `interrupt_core_list` mentionnés précédemment. Si le cas d'utilisation des services que vous avez lancés nécessite des cœurs supplémentaires ou des cœurs moins encombrés, suivez cette section.
Vérifiez l'affinité avec laquelle votre service est actuellement configuré à l'aide de la commande :
```
systemctl show --property CPUAffinity
```
Si vous voyez une valeur vide telle que`CPUAffinity=`, cela signifie qu'elle utilisera probablement les cœurs par défaut de la commande ci-dessus `...bin/set_irq_affinity.sh ...`
Pour remplacer et définir une affinité spécifique, recherchez l'emplacement du fichier de service en exécutant :
```
systemctl show -p FragmentPath
```
Ouvrez et modifiez le fichier (en utilisant `vi``nano`, etc.) et placez-le `CPUAffinity=` dans la `[Service]` section comme suit :
```
[Unit]
...
[Service]
...
CPUAffinity=2,3
[Install]
...
```
Enregistrez le fichier et redémarrez le service pour appliquer l'affinité avec :
```
systemctl daemon-reload
systemctl restart
# Additionally confirm by re-running
systemctl show --property CPUAffinity
```
Pour plus d'informations, consultez : [Red Hat Enterprise Linux 8 - Gestion, surveillance et mise à jour du noyau - Chapitre 27. Configuration de l'affinité du processeur et des politiques NUMA à l'aide de systemd](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).
### Processus d'affinisation (scripts)
Il est fortement recommandé d'affinitialiser manuellement les scripts et processus récemment lancés, car le comportement Linux par défaut leur permet d'utiliser n'importe quel cœur de la machine.
Pour éviter les conflits de base entre les processus en cours d'exécution (tels que python, scripts bash, etc.), lancez le processus avec :
```
taskset -c
# Example: taskset -c 8 ./bashScript.sh
```
Si le processus est déjà en cours d'exécution, utilisez des commandes telles que `pidof``top`, ou `ps` pour trouver l'ID de processus (PID) du processus spécifique. Avec le PID, vous pouvez voir l'affinité actuelle avec :
```
taskset -p
```
et vous pouvez le modifier avec :
```
taskset -p
# Example: taskset -p c 32392 (which sets it to cores 0xc -> 0b1100 -> cores 2,3)
```
Pour plus d'informations sur le jeu de tâches, voir la page de manuel de [jeu de tâches - Linux](https://linux.die.net/man/1/taskset)