Kipmi0 makan hingga 99,8% cpu pada centos 6.4


15

Kami memiliki CentOS 6.4 dan kipmi0ditampilkan sebagai 99,8% CPU dan memori 0,0% dan rata-rata beban 1,00. Apa yang harus kita lakukan untuk memperbaiki ini?


Anda harus mulai dengan membaca www-01.ibm.com/support/…
squareborg

2
@ Saya telah membacanya sebelumnya jadi ia hanya mengatakan abaikan saja saya abaikan tetapi mesin saya yang lain tidak mengalami masalah ini?
biz14

Apakah sistem lain identik dengan sistem ini? Anda harus menentukan bahwa itu benar. Pasti ada sesuatu yang secara fundamental berbeda di antara mereka. Firmware? Versi RPM yang sama?
slm

@Ya ada dua mesin yang sama dengan centos yang sama 6.4 apa yang harus saya cari sekarang?
biz14

Bandingkan keluaran dari lshwdan dmidecodeakan menjadi area saya berikutnya untuk melihat.
slm

Jawaban:


5

Men-debug masalah

Apakah sistem lain identik dengan sistem ini? Anda harus menentukan bahwa itu benar. Pasti ada sesuatu yang secara fundamental berbeda di antara mereka. Firmware? Versi RPM yang sama?

Anda dapat menggunakan alat-alat seperti lshw, dmidecode, dan melihat dmesglog untuk petunjuk tentang apa yang berbeda dan apa akar penyebab.

Saya akan mendapatkan garis dasar yang baik dari RPM yang diinstal dengan menjalankan perintah ini di salah satu sistem yang tidak menunjukkan masalah ini dan yang ada dan membandingkan daftar paket untuk memastikan mereka semua pada versi yang sama.

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

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

Kemudian dapatkan file pada mesin yang sama dan lakukan sdiff dari 2 file:

 sdiff machine1_rpms.txt machine2_rpms.txt

Penyebab potensial # 1

Situs web IBM memiliki teknik ini berjudul: Kipmi0 Mei Menunjukkan Peningkatan Pemanfaatan CPU di Linux , mengenai masalah ini. Menurut masalah ini Anda pada dasarnya dapat mengabaikan masalah.

deskripsi masalah

Proses kipmi0 dapat menunjukkan peningkatan pemanfaatan CPU di Linux. Pemanfaatan dapat meningkat hingga 100% ketika perangkat IPMI (Intelligent Platform Management Interface), seperti BMC (Baseboard Management Controller) atau IMM (Integrated Management Controller) sedang sibuk atau tidak responsif.

Memperbaiki

Tidak diperlukan perbaikan. Anda harus mengabaikan peningkatan pemanfaatan CPU karena tidak berdampak pada kinerja sistem yang sebenarnya.

Bekerja di sekitar

  1. Jika menggunakan perangkat IPMI, setel ulang BMC atau reboot sistem.
  2. Jika tidak menggunakan perangkat IPMI, hentikan layanan IPMI dengan mengeluarkan perintah berikut:

    layanan berhenti ipmi

Solusi potensial # 2

Saya menemukan posting ini di blog someones dengan judul: masalah kipmi0 . Masalah ini terdengar identik dengan masalah Anda. Masalah ini ditelusuri ke masalah dengan 2 modul kernel yang semakin dimuat sebagai bagian dari lm_sensorspaket.

Ini adalah 2 modul kernel:

  • ipmi_si
  • ipmi_msghandler

Bekerja di sekitar

Anda dapat menghapus ini secara manual dengan perintah berikut:

rmmod ipmi_msghandler
rmmod ipmi_si

Untuk membuat perbaikan ini permanen, Anda harus menonaktifkan pemuatan modul kernel ini di dalam salah satu lm_sensorsfile konfigurasi, dengan berkomentar seperti:

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

Mulai ulang lm_sensorssetelah melakukan perubahan ini:

/etc/init.d/lm_sensors

Saya telah mengunjungi situs web dan di sistem saya, saya tidak menemukan file ini / etc / sysconfig / lm_sensors. Sesuatu yang lucu ketika saya melakukan pengurutan pada file pertama adalah Asc tetapi file kedua adalah desc? Kedua, cara menampilkan perbedaan ke dalam file. Ya saya juga bisa melihat perbedaannya.
biz14

ya sekarang saya lakukan kedua kalinya diurutkan sesuai turun. Saya tidak mengerti cara menggunakan grep "|". Apa lagi yang harus saya lakukan untuk memperbaiki masalah ini?
biz14

Semua yang saya katakan adalah melakukan ini: sdiff machine1_rpms.txt machine2_rpms.txt | grep "|"akan mencabut semua perbedaan dengan 2 file .txt. Ada cara lain untuk melakukannya tetapi itu satu cara.
slm

Saya menjalankan perintah ini dan di sini adalah output 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. 12_rpms adalah mesin masalah dan yang lainnya tanpa masalah. Tetapi ketika saya secara manual melihat 12_rpms memiliki 247 baris dan 11_rpms memiliki 263 tetapi sdiff hanya satu? Jadi apa yang harus saya langkah selanjutnya berdasarkan perbedaan ini?
biz14

Silakan posting file-file ini juga di pastebin.com .
slm

24

Menurut Dokumen IPMI :

utas ini dapat menggunakan banyak CPU tergantung pada kinerja antarmuka. Ini dapat menghabiskan banyak CPU dan menyebabkan berbagai masalah dengan mendeteksi CPU yang menganggur dan menggunakan daya ekstra. Untuk menghindari ini, kipmid_max_busy_us menetapkan jumlah waktu maksimum, dalam mikrodetik, bahwa kipmid akan berputar sebelum tidur untuk tanda centang. Nilai ini menetapkan keseimbangan antara kinerja dan pemborosan CPU dan perlu disesuaikan dengan kebutuhan Anda. Mungkin, suatu hari, penyetelan otomatis akan ditambahkan, tetapi itu bukan hal yang sederhana dan bahkan penyetelan otomatis perlu disesuaikan dengan kinerja yang diinginkan pengguna.

Jadi, kita dapat menjalankan perintah ini untuk mengatur parameter kipmid_max_busy_us:

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

Dalam sistem kami, setelah mengatur parameter ini, cpu kipmi0 menurun hingga 15%.

Anda bisa mencoba ini.

Untuk membuat perubahan terus-menerus, Anda dapat mengkonfigurasi opsi untuk modul kernel ipmi_si.
Buat file di /etc/modprobe.d/, yaitu /etc/modprobe.d/ipmi.conf, dan tambahkan konten berikut: Sekarang setiap kali modul ipmi_si dimuat ke dalam kernel, parameter harus secara otomatis dan benar diatur.
# Prevent kipmi0 from consuming 100% CPU
options ipmi_si kipmid_max_busy_us=100


Meskipun ini mungkin jawaban yang benar, ini dianggap praktik terbaik di situs SE untuk merinci alasan sebagai bagian dari jawaban Anda, serta mengutip setiap tautan eksternal. Dengan begitu, jika tautan eksternal menjadi tidak berfungsi, logika dan alasannya masih dapat dilihat di sini.
Drav Sloan

Apakah ada cara standar untuk membuatnya berlaku secara permanen?
tgharold

Pada CentOS / RHEL, perintah itu dapat dibuat permanen dengan menambahkannya ke /etc/rc.d/rc.local. Rc.local berjalan setelah semua skrip init lainnya.
tgharold

1

kipmi0 dapat dinonaktifkan pada CentOS 6 seluruhnya dengan menambahkan ipmi_si.force_kipmid=0sebagai parameter kernel

Tes di layar boot GRUB dengan menyorot kernel yang ingin Anda boot, tekan 'a' untuk memodifikasi parameter dan menambahkan ipmi_si.force_kipmid=0

Jadikan permanen dengan menambahkan ipmi_si.force_kipmid=0ke baris kernel yang relevan di/boot/grub/grub.conf

CATATAN: Dalam distro yang memiliki ipmi_si sebagai modul kernel terpisah, menggunakan file modprobe.d conf lebih tepat. Dalam CentOS ipmi_si dibangun di dalam gambar kernel, jadi konfigurasi modprobe tidak berfungsi.


1

CentOS 6 memiliki driver ipmi yang dikompilasi dalam kernel. Jika Anda tidak memerlukan dukungan ipmi maka nonaktifkan saja grub.conf

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

1

Saya menemukan bantuan berikut dengan masalah ini:

ipmitool bmc info

Ini sepertinya membangunkan IPMI dan kemudian berhenti menggunakan 100% inti.

Saya juga menemukan yang berikut ini bermanfaat:

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

Juga di masa lalu saya telah mampu pada beberapa server untuk menyelesaikan penggunaan CPU 100% dengan:

ipmitool lan print

dan

ipmitool bmc reset cold

tetapi dalam pengalaman saya yang terbaru opsi di atas hanya akan menyebabkan ipmitooltidak responsif dan duduk di sana, menyebabkan saya untuk Ctrl+ Citu.

Semoga ini bisa membantu seseorang.


Apakah ada masalah yang harus dilakukan echo 1 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us?
Qian Chen

0

Saya menemukan ini menjalankan CentOS 7 dan mencoba mencari tahu apa yang mengambilnya.

Bagi saya, itu adalah "ipmicfg" Supermicro yang berjalan dari skrip yang saya tulis atau apalah. Saya baru saja pkill dan penggunaan kipmi0 hilang.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.