Kipmi0 mangeant jusqu'à 99,8% de CPU sur Centos 6.4

Nous avons CentOS 6.4 et l' kipmi0affiche à 99,8% de processeur et 0,0% de mémoire et la charge moyenne est de 1,00. Que devons-nous faire pour rectifier cela?

Débogage du problème

Les autres systèmes sont-ils identiques à ce système? Vous devrez déterminer qu'ils le sont. Il doit y avoir quelque chose de fondamentalement différent entre eux. Firmware? Mêmes versions RPM?

Vous pouvez utiliser des outils tels que lshw, dmidecodeet regardant le dmesgjournal des indices quant à ce qui est différent et ce qui est la cause racine.

J'obtiendrais une bonne base de référence des RPM installés en exécutant cette commande sur l'un des systèmes qui ne présentent pas ce problème et celui qui l'est et comparer les listes de packages pour vous assurer qu'ils sont tous dans les mêmes versions.

 # machine #1
 $ rpm -aq | sort -rn > machine1_rpms.txt

 # machine #2
 $ rpm -aq | sort -rn > machine2_rpms.txt     

Ensuite, récupérez les fichiers sur la même machine et faites une différence des 2 fichiers:

 sdiff machine1_rpms.txt machine2_rpms.txt

Cause potentielle n ° 1

Le site Web d'IBM avait cette note technique intitulée: Kipmi0 peut montrer une utilisation accrue du processeur sous Linux , concernant ce problème. Selon ce problème, vous pouvez essentiellement ignorer le problème.

Description du problème

Le processus kipmi0 peut montrer une utilisation accrue du processeur sous Linux. L'utilisation peut augmenter jusqu'à 100% lorsque le périphérique IPMI (Intelligent Platform Management Interface), tel qu'un contrôleur BMC (Baseboard Management Controller) ou IMM (Integrated Management Controller) est occupé ou ne répond pas.

Réparer

Aucun correctif requis. Vous devez ignorer l'utilisation accrue du processeur car elle n'a aucun impact sur les performances réelles du système.

Solution de contournement

1. Si vous utilisez un périphérique IPMI, réinitialisez le contrôleur BMC ou redémarrez le système.

2. Si vous n'utilisez pas de périphérique IPMI, arrêtez le service IPMI en exécutant la commande suivante:

   service ipmi stop

Solution potentielle # 2

J'ai trouvé cet article sur le blog de quelqu'un simplement intitulé: problème kipmi0 . Ce problème semblait identique au vôtre. Le problème a été attribué à un problème avec 2 modules du noyau qui étaient chargés dans le cadre du lm_sensorspackage.

Ce sont les 2 modules du noyau:

• ipmi_si
• ipmi_msghandler

Solution de contournement

Vous pouvez les supprimer manuellement avec les commandes suivantes:

rmmod ipmi_msghandler
rmmod ipmi_si

Pour rendre ce correctif permanent, vous devrez désactiver le chargement de ces modules de noyau particuliers dans l'un des lm_sensorsfichiers de configuration, en les commentant comme suit:

# /etc/sysconfig/lm_sensors
# MODULE_0=ipmi-si
# MODULE_1=ipmisensors
# MODULE_2=coretemp

Redémarrez lm_sensorsaprès avoir apporté ces modifications:

/etc/init.d/lm_sensors

Selon le document IPMI :

ce thread peut utiliser beaucoup de CPU en fonction des performances de l'interface. Cela peut gaspiller beaucoup de CPU et provoquer divers problèmes de détection de CPU inactif et d'utilisation de puissance supplémentaire. Pour éviter cela, le kipmid_max_busy_us définit la durée maximale, en microsecondes, pendant laquelle le kipmid tournera avant de dormir pour un tick. Cette valeur établit un équilibre entre les performances et le gaspillage du processeur et doit être adaptée à vos besoins. Peut-être qu'un jour, le réglage automatique sera ajouté, mais ce n'est pas une chose simple et même le réglage automatique devrait être réglé en fonction des performances souhaitées par l'utilisateur.

Donc, nous pouvons exécuter cette commande pour définir le paramètre kipmid_max_busy_us:

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

Dans notre système, après avoir défini ce paramètre, le processeur de kipmi0 a diminué à 15%.

Vous pouvez essayer ça.

Pour rendre les modifications persistantes, vous pouvez configurer les options du module du noyau ipmi_si.
Créez un fichier dans /etc/modprobe.d/, c'est- à -dire /etc/modprobe.d/ipmi.conf, et ajoutez le contenu suivant: Maintenant, chaque fois que le module du noyau ipmi_si est chargé dans le noyau, le paramètre doit être automatiquement et correctement défini.
# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100

kipmi0 peut être entièrement désactivé sur CentOS 6 en ajoutant ipmi_si.force_kipmid=0comme paramètre de noyau

Testez à l'écran de démarrage GRUB en mettant en surbrillance le noyau que vous souhaitez démarrer, appuyez sur 'a' pour modifier les paramètres et ajouter ipmi_si.force_kipmid=0

Rendre permanent en ajoutant ipmi_si.force_kipmid=0aux lignes de noyau pertinentes dans/boot/grub/grub.conf

REMARQUE: dans les distributions qui ont ipmi_si comme module de noyau séparé, l'utilisation d'un fichier de configuration modprobe.d est plus appropriée. Dans CentOS, ipmi_si est intégré à l'image du noyau, donc les configurations modprobe ne fonctionnent pas.

CentOS 6 a un pilote ipmi compilé dans le noyau. Si vous n'avez pas besoin du support ipmi, désactivez-le simplement grub.conf

ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0

J'ai trouvé les aides suivantes avec ce problème:

ipmitool bmc info

Cela semble réveiller IPMI, puis il arrête d'utiliser 100% d'un cœur.

J'ai également trouvé les informations suivantes utiles:

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

Dans le passé, j'ai également été en mesure sur certains serveurs de résoudre l'utilisation à 100% du processeur en:

ipmitool lan print

et

ipmitool bmc reset cold

mais dans ma plus récente expérience, les options ci-dessus ne feraient que ipmitoolne pas répondre et resteraient là, m'obligeant à le Ctrl+ C.

J'espère que cela aide quelqu'un.

J'ai trouvé cela en cours d'exécution CentOS 7 et en essayant de comprendre ce qui se passait.

Pour moi, c'était "ipmicfg" de Supermicro à partir d'un script que j'ai écrit ou quelque chose. Je l'ai juste tué et l'utilisation de kipmi0 a disparu.