Comment désactiver un processeur

Après avoir fait quelques tests, j'ai obtenu les résultats ci-dessous :

echo 0 > /sys/devices/system/cpu/cpu4/online

désactive le 4ème CPU.

"désactiver le 4ème CPU" signifie que les derniers processus ne seront plus affectés au 4ème CPU. En d'autres termes, les processus situés sur le 4ème CPU avant "désactiver le 4ème CPU" ne seront pas déplacés hors du CPU lors de la désactivation du CPU.

En disant que j'ai quatre CPU :0, 1, 2 et 3. Donc je peux :

echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online
./MyShell.sh

pour forcer le ./MyShell.sh à affecter au CPU0.

Au fait, le redémarrage activera automatiquement tous les processeurs.

Outre la réponse de @Yves, vous pouvez en fait utiliser le isolcpus paramètre du noyau.

Pour désactiver le 4e CPU/cœur (CPU 3) avec Debian ou Ubuntu :

En /etc/default/grub ajouter isolcpus=3 à GRUB_CMDLINE_LINUX_DEFAULT

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=3"

Exécuter

sudo update-grub

Redémarrez le serveur.

isolcpus – Isolez les processeurs du planificateur du noyau.

Synopsis isolcpus=numéro_processeur [, numéro_processeur ,...]

Description Supprime les processeurs spécifiés, tels que définis par les valeurs cpu_number, de l'équilibrage SMP général du noyau et des scheduleralgroithms. La seule façon de déplacer un processus vers ou hors d'un CPU "isolé" est via les appels système d'affinité CPU. cpu_number commence à 0, donc la valeur maximale est 1 de moins que le nombre de processeurs sur le système.

Cette option est la méthode préférée pour isoler les processeurs. L'alternative, la définition manuelle du masque de processeur de toutes les tâches du système, peut entraîner des problèmes et des performances sous-optimales de l'équilibreur de charge.

Il est intéressant de noter que l'utilisation de ces paramètres du noyau peut consister à réserver un processeur pour plus tard en utilisant l'affinité du processeur avec un processus/épingler un processus à un processeur, et donc à la fois de s'assurer qu'il n'y a plus de processus utilisateur en cours d'exécution sur ce processeur.

De plus, cela peut également rendre le serveur plus stable en garantissant qu'un processus particulier avec une charge très élevée aura ses propres processeurs avec lesquels jouer. J'ai vu Meru faire cela avec leurs contrôleurs basés sur Linux avant de prendre conscience de cette configuration.

La commande associée pour ensuite affecter un processus au quatrième CPU (CPU 3), est :

sudo taskset -cp PID

taskset est utilisé pour définir ou récupérer l'affinité CPU d'un processus en cours d'exécution en fonction de son PID ou pour lancer une nouvelle COMMANDE avec une affinité CPU donnée. L'affinité CPU est une propriété du planificateur qui « lie » un processus à un ensemble donné de CPU sur le système. Le planificateur Linux respectera l'affinité CPU donnée et le processus ne s'exécutera sur aucun autre processeur. Notez que le planificateur Linux prend également en charge l'affinité CPU naturelle :le planificateur tente de conserver les processus sur le même CPU aussi longtemps que possible pour des raisons de performances. Par conséquent, forcer une affinité CPU spécifique n'est utile que dans certaines applications.

RÉSUMÉ

Il existe plusieurs techniques appliquées à cette question :

définir isolcpus = 4 dans grub et le redémarrage peut désactiver le 5e CPU/CPU 4 de manière permanente pour les processus utilisateur land ;

echo 0 > /sys/devices/system/cpu/cpu4/online désactive le 5ème CPU/CPU 4, qui continuera à fonctionner pour les processus qui lui ont déjà été affectés mais aucun nouveau processus ne sera plus affecté au CPU 4 ;

taskset -c 3 ./MyShell.sh forcera MyShell.sh à affecter au 4ème CPU/CPU 3 alors que le 4ème CPU peut toujours accepter d'autres processus utilisateur land si isolcpus ne l'empêche pas de le faire.

PS. Pour l'anecdote, mon meilleur exemple d'utilisation du isolcpus /taskset sur le terrain, était une interface SSL pour un très occupé site, qui restait instable toutes les deux semaines, où Ansible/ssh ne me laisserait plus entrer à distance.

J'ai appliqué les techniques décrites ci-dessus, et cela a continué à fonctionner de manière très stable depuis.