Linux内核错误，求解决方法！！

realsykow

这几天服务器CPU使用率经常超高，导致监控程序都连接不上服务器，一直在告警。查看服务器日志如下。请问这个问题应该怎么解决啊

Nov 29 22:03:32 localhost kernel: BUG: soft lockup - CPU#0 stuck for 66s! [login:29614]
Nov 29 22:03:32 localhost kernel: Modules linked in: iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_mangle ip_tables nls_utf8 autofs4 sunrpc xt_multiport xt_iprange ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ppdev parport_pc parport microcode vmware_balloon vmxnet3 sg i2c_piix4 i2c_core shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom mptspi mptscsih mptbase scsi_transport_spi pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
Nov 29 22:03:32 localhost kernel: CPU 0
Nov 29 22:03:32 localhost kernel: Modules linked in: iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_mangle ip_tables nls_utf8 autofs4 sunrpc xt_multiport xt_iprange ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ppdev parport_pc parport microcode vmware_balloon vmxnet3 sg i2c_piix4 i2c_core shpchp ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom mptspi mptscsih mptbase scsi_transport_spi pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
Nov 29 22:03:32 localhost kernel:
Nov 29 22:03:32 localhost kernel: Pid: 29614, comm: login Not tainted 2.6.32-358.el6.x86_64 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform
Nov 29 22:03:32 localhost kernel: RIP: 0033:[<00007fffd31ff850>]  [<00007fffd31ff850>] 0x7fffd31ff850
Nov 29 22:03:32 localhost kernel: RSP: 002b:00007f365bffeb70  EFLAGS: 00000212
Nov 29 22:03:32 localhost kernel: RAX: 2f1d9c83df6d65c3 RBX: 00007f365bffeb80 RCX: 0000000000000000
Nov 29 22:03:32 localhost kernel: RDX: 000000008126c011 RSI: 00000000565b0487 RDI: 00007f365bffebf0
Nov 29 22:03:32 localhost kernel: RBP: ffffffff8100bb8e R08: 00000000025ebc70 R09: 00000000000073ae
Nov 29 22:03:32 localhost kernel: R10: 0000007900000073 R11: 0000000000000000 R12: 00007f365bffeb80
Nov 29 22:03:32 localhost kernel: R13: 0000000000000003 R14: 0000000000000000 R15: 00007f365bfff9c0
Nov 29 22:03:32 localhost kernel: FS:  00007f365bfff700(0000) GS:ffff880028200000(0000) knlGS:0000000000000000
Nov 29 22:03:32 localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 29 22:03:32 localhost kernel: CR2: 00007f3a8a6ca000 CR3: 000000013c659000 CR4: 00000000000407f0
Nov 29 22:03:32 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 29 22:03:32 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 29 22:03:32 localhost kernel: Process login (pid: 29614, threadinfo ffff88013b2de000, task ffff88013c600aa0)

tomshenhao

Soft lockup messages from Linux kernel running in an SMP-enabled virtual machine (1009996)

Details
When running a Linux kernel in a symmetric multiprocessing (SMP) enabled virtual machine, messages similar to BUG: soft lockup detected on CPU#1! are written to the message log file. The exact format of these messages vary from kernel to kernel, and might be accompanied by a kernel stack backtrace.

Many Linux kernels have a soft lockup watchdog thread, and report soft lockup messages if that watchdog thread does not get scheduled for more than 10 seconds. On a physical host, a soft lockup message generally indicates a kernel bug or hardware bug. When running in a virtual machine, this might instead indicate high levels of overcommitment (especially memory overcommitment) or other virtualization overheads.
Solution
The soft lockup messages are not kernel panics, and generally appears when the virtual machine is using a large amount of its resources.

To stop the error messages from appearing as frequently:

Some kernels allow you to adjust the soft lockup threshold by running the command:

echo time > /proc/sys/kernel/softlockup_thresh

Where time is the number of seconds after which a soft lockup is reported. The default is generally 10 seconds.