服务器在负载下冻结

Question

我在debian服务器上遇到了问题，我认为这是由于内存不好造成的，但一直存在。

它是一个戴尔Poweredge 6800，有两个双核3.6GHZ Xeon处理器和5GB的DDR2 ECC 333。

我有一个73 got的SCSI驱动器。

我现在就快死了，从MySQL中提取记录，构建触发.call调用的星号.call文件(小文本文件)。

我们通过一个cgi接口来管理它，系统也在为我们的邮件运行城堡，但是我们只有不到五个用户。不是很大的排水沟。

我的最高使用量似乎是每分钟460次左右。Load徘徊在2.04.3之间，如果我把它推过去，它会猛增到>22.0。

我现在遇到的问题是，打了一个小时的电话，我就觉得冷死了。昨晚我5点59分启动，6点55分17秒，系统没有反应。没有任何记录，我无法通过ssh或http连接，它响应ping，nmap显示了开放的端口，我可以告诉它，但没有得到任何响应。

我的sar数据收集工作是在6:50进行的，当时，我看到了大量的使用，正如我所预期的那样，但据我所知，并没有什么惊人的事情。

系统一直在抱怨我安装的一个新的2GB条内存错误，所以在第一次崩溃后，我用我们升级的512 we条替换了这一对。

我目前正在拨号，运行一个实时sar数据集，以防它再次崩溃。至少我可以用更多的粒度拨进来。

除此之外，我不知道如何在没有任何相关日志数据或崩溃转储的情况下诊断系统冻结。因为系统还在运行，但在这段时间内完全没有反应，直到我执行一个电源循环。有什么想法吗？

注意:我有新的服务器，以便通过分发服务来减轻这个系统的一些负载，但同时，我们的生产也依赖于这个工作马。

这是昨晚坠机的Sar数据.

更新：此sar快照以10秒的增量运行，最后一次采集是在冻结前1秒.

我购买了一个终端控制台服务器，现在可以看到系统冻结时发生了什么。

这组消息大约每30秒重复一次，通过CPU1和CPU2循环。

[17675.940127] BUG: soft lockup - CPU#1 stuck for 61s! [asterisk:4579]
[17675.940127] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs reiserfs ext]
[17675.940127] 
[17675.940127] Pid: 4579, comm: asterisk Not tainted (2.6.32-5-686-bigmem #1) PowerEdge 6800
[17675.940127] EIP: 0060:[<c1024c6f>] EFLAGS: 00000202 CPU: 1
[17675.940127] EIP is at native_flush_tlb_others+0x85/0xa6
[17675.940127] EAX: 00000282 EBX: c14620ac ECX: c102fb3a EDX: 00000020
[17675.940127] ESI: 00000001 EDI: 00000040 EBP: c14620a0 ESP: f35d1a3c
[17675.940127]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[17675.940127] CR0: 80050033 CR2: b3f06946 CR3: 36787000 CR4: 000006f0
[17675.940127] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[17675.940127] DR6: ffff0ff0 DR7: 00000400
[17675.940127] Call Trace:
[17675.940127]  [<c1024d57>] ? flush_tlb_page+0x5d/0x65
[17675.940127]  [<c1024144>] ? ptep_set_access_flags+0x59/0x63
[17675.940127]  [<c10a13c8>] ? do_wp_page+0x3b9/0x7dd
[17675.940127]  [<c1025a1d>] ? kmap_atomic_prot+0xd7/0xfc
[17675.940127]  [<c10a3173>] ? handle_mm_fault+0x982/0xa22
[17675.940127]  [<c104d52d>] ? lock_hrtimer_base+0x15/0x2f
[17675.940127]  [<c104d5ab>] ? hrtimer_try_to_cancel+0x2f/0x35
[17675.940127]  [<c12823e8>] ? do_page_fault+0x2f1/0x307
[17675.940127]  [<c12820f7>] ? do_page_fault+0x0/0x307
[17675.940127]  [<c1280923>] ? error_code+0x73/0x78
[17675.940127]  [<c10c00d8>] ? copy_strings+0x94/0x1ba
[17675.940127]  [<c10c6b8a>] ? do_sys_poll+0x2c3/0x312
[17675.940127]  [<c10c7586>] ? __pollwait+0x0/0xa5
[17675.940127]  [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127]  [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127]  [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127]  [<c10c762b>] ? pollwake+0x0/0x65
[17675.940127]  [<c1026614>] ? activate_task+0x1e/0x24
[17675.940127]  [<c1032713>] ? push_rt_task+0x208/0x242
[17675.940127]  [<c102acb9>] ? post_schedule+0x31/0x3e
[17675.940127]  [<c127f5d6>] ? schedule+0x78f/0x7dc
[17675.940127]  [<c10567d5>] ? futex_wait_setup+0x5c/0xcd
[17675.940127]  [<c10568cd>] ? futex_wait_queue_me+0x87/0x98
[17675.940127]  [<c100c96a>] ? sched_clock+0x5/0x7
[17675.940127]  [<c1091b00>] ? zone_watermark_ok+0x16/0x99
[17675.940127]  [<c1087baa>] ? cpupri_find+0x4c/0xd6
[17675.940127]  [<c109270c>] ? get_page_from_freelist+0xc0/0x3c7
[17675.940127]  [<c102d917>] ? check_preempt_curr_rt+0x76/0xe3
[17675.940127]  [<c1024e31>] ? smp_invalidate_interrupt+0x73/0x86
[17675.940127]  [<c1092cd4>] ? __alloc_pages_nodemask+0xf3/0x4d9
[17675.940127]  [<c113d358>] ? cpumask_any_but+0x20/0x2b
[17675.940127]  [<c1024d44>] ? flush_tlb_page+0x4a/0x65
[17675.940127]  [<c127fe16>] ? mutex_lock+0xb/0x24
[17675.940127]  [<c10bb225>] ? do_sync_read+0xc0/0x107
[17675.940127]  [<c10438d5>] ? do_send_sig_info+0x4f/0x59
[17675.940127]  [<c104a97a>] ? autoremove_wake_function+0x0/0x2d
[17675.940127]  [<c1051af5>] ? ktime_get_ts+0xcd/0xd5
[17675.940127]  [<c10c6d2b>] ? sys_poll+0x44/0x8d
[17675.940127]  [<c100813b>] ? sysenter_do_call+0x12/0x28

第一次迭代列出了另一组模块。

[267866.376128] Modules linked in: cpufreq_powersave cpufreq_stats cpufreq_conservative cpufreq_userspace parport_pc ppdev lp parport sco bridge stp bnep rfcomm l2cap crc16 bluetooth rfkill nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc fuse loop radeon ttm psmouse drm_kms_helper serio_raw evdev pcspkr drm i2c_algo_bit rng_core i2c_core dcdbas shpchp button pci_hotplug processor ext3 jbd mbcache sd_mod crc_t10dif sg sr_mod cdrom ata_generic uhci_hcd ata_piix mptspi mptscsih ehci_hcd mptbase usbcore nls_base libata tg3 scsi_transport_spi scsi_mod floppy libphy thermal thermal_sys [last unloaded: scsi_wait_scan]

我安装了intel-microcode microcode.ctl，没有像其他论坛所建议的那样，知道如何禁用超线程。

Answer 1

我认为这种模式可能与写入时的I/O太高而磁盘没有同步有关。这将解释为什么负载突然激增，在此期间没有任何记录，这最终解决了自己。

如果是这样的话，当系统冻结时/proc/meminfo将显示"Dirty“的高值，您可能会看到dmesg/syslog消息如下：

INFO: task syslogd:1500 blocked for more than 120 seconds. 
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 
syslogd D 0000000000000110 0 1500 1 1503 1491 (NOTLB) 
 ffff8800b0739d88 0000000000000286 ffff8800b8922970 ffff8800b8922970 
 0000000000000009 ffff8800bb2dd0c0 ffff8800baa55080 0000000000002b40 
 ffff8800bb2dd2a8 0000000000000000 
Call Trace: 
 [] :jbd:log_wait_commit+0xa3/0xf5 
 [] autoremove_wake_function+0x0/0x2e 
 [] :jbd:journal_stop+0x1cf/0x1ff 
 [] __writeback_single_inode+0x1d9/0x318 
 [] do_readv_writev+0x26e/0x291 
 [] sync_inode+0x24/0x33 
 [] :ext3:ext3_sync_file+0xcc/0xf8 
 [] do_fsync+0x52/0xa4 
 [] __do_fsync+0x23/0x36 
 [] tracesys+0xab/0xb6

如果正在发生这种情况，您将不得不找到一些方法来减少写入的负担，通过节流，或者缓存，或者可能通过将磁盘调度程序切换到noop，或者.有时候，在这个问题上抛出内存会有帮助，因为系统能够在冻结之前容忍“脏”内存中更大的尖峰。

Answer 2

有几件事你可以尝试获得更多的信息：

• 如果您认为您的服务器完全崩溃，如果您由于某些原因无法访问默认控制台，您可能可以从网络控制台获得信息。
• 如果您正在使用-p标志运行星号，并且它可能正在生动活泼地锁定系统，您可以尝试确保您可以创建一个新的shell，如：# for pid in `pidof sshd`; do chrt -p -f 99 $pid; done。
• 您还可以尝试设置以下选项，以便在内核检测到问题时自动重新启动：# sysctl -w kernel.panic_on_oops=1; sysctl -w kernel.panic=1; sysctl -w kernel.softlockup_panic=1。