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

Meilleures pratiques Amazon EC2

Suivez les meilleures pratiques EC2 actuelles et garantissez une disponibilité suffisante du stockage des données.

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 épinglés à un cœur spécifique. Tout thread qui envoie ou reçoit des données UDP doit se connecter à un cœur spécifique pendant la durée de transmission des données.

AWS Ground Station liste de préfixes gérée

Il est recommandé d'utiliser la liste de com.amazonaws.global.groundstation AWS-managed préfixes pour spécifier les règles du réseau afin d'autoriser la communication depuis l'antenne. Consultez la section Utilisation des listes de préfixes gérées par AWS pour plus d'informations sur les listes de préfixes gérées AWS.

Limitation de 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 terminaux de flux de données. Si une configuration d'agent unique est associée à plusieurs ARN DFEG différents, elle ne sera pas enregistrée.

Exécution de services et de processus parallèlement à 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 aux processeurs virtuels qui ne sont pas utilisés par l' AWS Ground Station agent et le noyau Linux, car cela peut provoquer des goulots d'étranglement et même des pertes de données lors des contacts. Ce concept de liaison à des vCPU spécifiques est connu sous le nom d'affinité.

Noyaux à éviter :

Par exemple, en utilisant une instance c5.24xlarge

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

évitez alors les noyaux suivants :

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

Services d'affinitialisation (systemd)

Les services récemment lancés s'affinitieront automatiquement à ceux 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 nécessite 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 <service name>
                

Si vous voyez une valeur vide telle queCPUAffinity=, cela signifie qu'elle utilisera probablement les cœurs par défaut de la commande ci-dessus ...bin/set_irq_affinity.sh <using the cores here> ...

Pour modifier et définir une affinité spécifique, recherchez l'emplacement du fichier de service en exécutant :

systemctl show -p FragmentPath <service name>
                

Ouvrez et modifiez le fichier (en utilisant vinano, etc.) et placez-le CPUAffinity=<core list> 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 <service name>

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

Pour plus d'informations, consultez : Red Hat Enterprise Linux 8 - Gestion, surveillance et mise à jour du noyau - Chapitre 27. Configuration des politiques d'affinité du processeur et de NUMA à l'aide de systemd.

Processus d'affinitialisation (scripts)

Il est fortement recommandé d'affinitialiser manuellement les scripts et les processus récemment lancés, car le comportement par défaut de Linux leur permettra d'utiliser n'importe quel cœur de la machine.

Pour éviter les conflits de base pour tous les processus en cours d'exécution (tels que python, scripts bash, etc.), lancez le processus avec :

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

Si le processus est déjà en cours d'exécution, utilisez des commandes telles que pidoftop, ou ps pour rechercher l'ID de processus (PID) du processus spécifique. Avec le PID, vous pouvez voir l'affinité actuelle avec :

taskset -p <pid>
                

et vous pouvez le modifier avec :

taskset -p <core mask> <pid>
# 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, consultez la page de manuel Taskset - Linux