@ Lo he leído antes, así que solo dice ignorar, ¿debería ignorarlo pero mis otras máquinas no tienen este problema?
biz14
¿Los otros sistemas son idénticos a este sistema? Tendrás que determinar que lo son. Tiene que haber algo que sea fundamentalmente diferente entre ellos. Firmware? ¿Las mismas versiones de RPM?
slm
@ Sí, hay dos máquinas con los mismos centos 6.4 ¿Qué debo buscar ahora?
biz14
Compare los resultados de lshwy dmidecodeserían mis próximas áreas para examinar.
slm
Respuestas:
5
Depuración del problema
¿Los otros sistemas son idénticos a este sistema? Tendrás que determinar que lo son. Tiene que haber algo que sea fundamentalmente diferente entre ellos. Firmware? ¿Las mismas versiones de RPM?
Puede usar herramientas como lshw, dmidecodey buscar en el dmesgregistro pistas sobre qué es diferente y cuál es la causa raíz.
Obtendría una buena línea de base de los RPM instalados al ejecutar este comando en uno de los sistemas que no presenta este problema y el que sí lo es, y comparar las listas de paquetes para asegurarme de que todos tengan las mismas versiones.
El proceso kipmi0 puede mostrar una mayor utilización de la CPU en Linux. La utilización puede aumentar hasta el 100% cuando el dispositivo IPMI (Interfaz de administración de plataforma inteligente), como un BMC (Controlador de administración de placa base) o IMM (Controlador de administración integrado) está ocupado o no responde.
Reparar
No se requiere arreglo. Debe ignorar la mayor utilización de la CPU, ya que no tiene ningún impacto en el rendimiento real del sistema.
Solución alterna
Si usa un dispositivo IPMI, reinicie el BMC o reinicie el sistema.
Si no utiliza un dispositivo IPMI, detenga el servicio IPMI emitiendo el siguiente comando:
servicio ipmi stop
Posible solución # 2
Encontré esta publicación en el blog de alguien simplemente titulada: problema kipmi0 . Este problema sonaba idéntico al tuyo. El problema se remonta a un problema con 2 módulos del núcleo que se estaban cargando como parte del lm_sensorspaquete.
Estos fueron los 2 módulos del núcleo:
ipmi_si
ipmi_msghandler
Solución alterna
Puede eliminarlos manualmente con los siguientes comandos:
rmmod ipmi_msghandler
rmmod ipmi_si
Para que esta solución sea permanente, necesitará deshabilitar la carga de estos módulos del kernel en particular dentro de uno de los lm_sensorsarchivos de configuración, al comentarlos así:
He estado en el sitio web y en mi sistema no encuentro este archivo / etc / sysconfig / lm_sensors. Algo gracioso cuando hago la ordenación en el primer archivo es Asc pero el segundo archivo es desc? En segundo lugar, cómo generar la diferencia en un archivo. Sí, también puedo ver muchas diferencias.
biz14
Sí, ahora lo hice la segunda vez que se ordena en consecuencia descendente. No entiendo cómo usar el grep "|". ¿Qué más debo hacer para rectificar este problema?
biz14
Todo lo que estaba diciendo era hacer esto: sdiff machine1_rpms.txt machine2_rpms.txt | grep "|"sacará todas las diferencias b / w de los 2 archivos .txt. Hay otras formas de hacerlo, pero esa es una forma.
slm
Ejecuté este comando y aquí está la salida sdiff 12_rpms.txt 11_rpms.txt | grep "|" perl-DBI-1.609-4.el6.x86_64 | perl-Digest-SHA-5.47-131.el6_4.x86_64. El 12_rpms es la máquina con problemas y el otro no tiene el problema. Pero cuando miro manualmente 12_rpms tienen 247 líneas y 11_rpms tienen 263, pero el sdiff es solo uno. Entonces, ¿cuál debería ser mi próximo paso ahora basado en esta diferencia?
biz14
Por favor, publique estos archivos también en pastebin.com .
este hilo puede usar mucha CPU dependiendo del rendimiento de la interfaz. Esto puede desperdiciar una gran cantidad de CPU y causar varios problemas al detectar la CPU inactiva y usar energía adicional. Para evitar esto, kipmid_max_busy_us establece la cantidad máxima de tiempo, en microsegundos, que kipmid girará antes de dormir por un tic. Este valor establece un equilibrio entre el rendimiento y el desperdicio de CPU y debe ajustarse a sus necesidades. Tal vez, algún día, se agregará el autoajuste, pero eso no es algo simple e incluso el autoajuste necesitaría ajustarse al rendimiento deseado del usuario.
Entonces, podemos ejecutar este comando para establecer el parámetro kipmid_max_busy_us:
En nuestro sistema, después de configurar este parámetro, la CPU de kipmi0 disminuyó al 15%.
Puedes probar esto.
Para que los cambios sean persistentes, puede configurar las opciones para el módulo del kernel ipmi_si.
Cree un archivo /etc/modprobe.d/, es decir /etc/modprobe.d/ipmi.conf, y agregue el siguiente contenido:
Ahora, cada vez que el módulo de kernel ipmi_si se carga en el kernel, el parámetro debe establecerse automática y correctamente. # Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100
Aunque esta puede ser la respuesta correcta, se considera la mejor práctica en los sitios de SE detallar el razonamiento como parte de su respuesta, así como citar los enlaces externos. De esa manera, si el enlace externo queda inactivo, la lógica y el razonamiento aún se pueden ver aquí.
Drav Sloan
¿Existe una forma estándar de hacer que eso surta efecto de forma permanente?
tgharold
En CentOS / RHEL, ese comando puede hacerse permanente agregándolo a /etc/rc.d/rc.local. El rc.local se ejecuta después de todos los otros scripts de inicio.
tgharold
1
kipmi0 se puede deshabilitar en CentOS 6 por completo al agregarlo ipmi_si.force_kipmid=0como parámetro del núcleo
Pruebe en la pantalla de inicio de GRUB resaltando el núcleo que desea iniciar, presione 'a' para modificar los parámetros y agregar ipmi_si.force_kipmid=0
Haga permanente agregando ipmi_si.force_kipmid=0a las líneas de kernel relevantes en/boot/grub/grub.conf
NOTA: En las distribuciones que tienen ipmi_si como un módulo de kernel separado, es más apropiado usar un archivo modprobe.d conf. En CentOS, ipmi_si está integrado en la imagen del núcleo, por lo que las configuraciones de modprobe no funcionan.
También en el pasado, en algunos servidores pude resolver el uso del 100% de la CPU al:
ipmitool lan print
y
ipmitool bmc reset cold
pero en mi experiencia más reciente, las opciones anteriores simplemente provocarían ipmitoolque no respondieran y se quedaran allí, lo que haría que Ctrl+ Clo hiciera .
lshw
ydmidecode
serían mis próximas áreas para examinar.Respuestas:
Depuración del problema
¿Los otros sistemas son idénticos a este sistema? Tendrás que determinar que lo son. Tiene que haber algo que sea fundamentalmente diferente entre ellos. Firmware? ¿Las mismas versiones de RPM?
Puede usar herramientas como
lshw
,dmidecode
y buscar en eldmesg
registro pistas sobre qué es diferente y cuál es la causa raíz.Obtendría una buena línea de base de los RPM instalados al ejecutar este comando en uno de los sistemas que no presenta este problema y el que sí lo es, y comparar las listas de paquetes para asegurarme de que todos tengan las mismas versiones.
Luego obtenga los archivos en la misma máquina y haga un sdiff de los 2 archivos:
Causa potencial n. ° 1
El sitio web de IBM tenía esta nota técnica titulada: Kipmi0 puede mostrar una mayor utilización de la CPU en Linux , con respecto a este problema. De acuerdo con este problema, esencialmente puede ignorar el problema.
descripción del problema
Reparar
Solución alterna
Si no utiliza un dispositivo IPMI, detenga el servicio IPMI emitiendo el siguiente comando:
servicio ipmi stop
Posible solución # 2
Encontré esta publicación en el blog de alguien simplemente titulada: problema kipmi0 . Este problema sonaba idéntico al tuyo. El problema se remonta a un problema con 2 módulos del núcleo que se estaban cargando como parte del
lm_sensors
paquete.Estos fueron los 2 módulos del núcleo:
Solución alterna
Puede eliminarlos manualmente con los siguientes comandos:
Para que esta solución sea permanente, necesitará deshabilitar la carga de estos módulos del kernel en particular dentro de uno de los
lm_sensors
archivos de configuración, al comentarlos así:Reinicie
lm_sensors
después de hacer estos cambios:fuente
sdiff machine1_rpms.txt machine2_rpms.txt | grep "|"
sacará todas las diferencias b / w de los 2 archivos .txt. Hay otras formas de hacerlo, pero esa es una forma.Según el documento de IPMI :
Entonces, podemos ejecutar este comando para establecer el parámetro kipmid_max_busy_us:
En nuestro sistema, después de configurar este parámetro, la CPU de kipmi0 disminuyó al 15%.
Puedes probar esto.
Para que los cambios sean persistentes, puede configurar las opciones para el módulo del kernel ipmi_si.
Cree un archivo
/etc/modprobe.d/
, es decir/etc/modprobe.d/ipmi.conf
, y agregue el siguiente contenido: Ahora, cada vez que el módulo de kernel ipmi_si se carga en el kernel, el parámetro debe establecerse automática y correctamente.# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100
fuente
kipmi0 se puede deshabilitar en CentOS 6 por completo al agregarlo
ipmi_si.force_kipmid=0
como parámetro del núcleoPruebe en la pantalla de inicio de GRUB resaltando el núcleo que desea iniciar, presione 'a' para modificar los parámetros y agregar
ipmi_si.force_kipmid=0
Haga permanente agregando
ipmi_si.force_kipmid=0
a las líneas de kernel relevantes en/boot/grub/grub.conf
NOTA: En las distribuciones que tienen ipmi_si como un módulo de kernel separado, es más apropiado usar un archivo modprobe.d conf. En CentOS, ipmi_si está integrado en la imagen del núcleo, por lo que las configuraciones de modprobe no funcionan.
fuente
CentOS 6 tiene un controlador ipmi compilado en el núcleo. Si no necesita soporte para ipmi, simplemente desactívelo grub.conf
fuente
Encontré las siguientes ayudas con este problema:
Esto parece despertar IPMI y luego deja de usar el 100% de un núcleo.
También encontré lo siguiente útil:
También en el pasado, en algunos servidores pude resolver el uso del 100% de la CPU al:
y
pero en mi experiencia más reciente, las opciones anteriores simplemente provocarían
ipmitool
que no respondieran y se quedaran allí, lo que haría que Ctrl+ Clo hiciera .Esperemos que esto ayude a alguien.
fuente
echo 1 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us
?Encontré esto ejecutando CentOS 7 y tratando de descubrir qué lo estaba tomando.
Para mí, fue el "ipmicfg" de Supermicro que se ejecutaba desde un script que escribí o algo así. Simplemente lo piqué y el uso de kipmi0 desapareció.
fuente