☰

服务器在负载下冻结

tag-icon • tag-icon apache-2.2 mysql debian asterisk
服务器在负载下冻结

我的 Debian 服务器出现了问题，我以为是 RAM 不好造成的，但问题一直存在。

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

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

我现在正在拼命工作，从 MySQL 中提取记录来构建触发 SIP 呼叫的星号 .call 文件（小文本文件）。

我们通过 cgi 接口进行管理，系统还运行 citadel 来处理我们的邮件，但我们的用户不到 5 人。这不会造成很大的负担。

我的峰值使用量似乎约为每分钟 460 个呼叫。负载在 2.0 - 4.3 之间徘徊，如果我将其推高至 4.3 以上，负载将飙升至 >22.0。

我遇到的问题是，拨号大约一个小时后，系统就冻结了。昨晚我 5:59 启动它，6:55:17 秒时，系统无响应。没有记录任何内容，我无法通过 ssh 或 http 连接，它响应 ping，nmap 显示开放端口，我可以通过 telnet 连接到这些端口，但无法从中获取任何响应。

我的 sar 数据收集在 6:50 运行，当时，我看到使用率很高，正如预期的那样，但据我所知，没有什么离谱的。

系统一直抱怨我安装的其中一个新 2GB 内存条出现内存错误，因此在第一次崩溃后，我用我们升级的 512MB 内存条替换了那对内存条。

我目前正在拨号，同时运行实时 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但还没有弄清楚如何禁用超线程，正如其他一些论坛所建议的那样。

答案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，或者......等等。有时，将内存投入到这个问题上会有所帮助，因为系统在冻结之前将能够容忍“脏”内存中更大的峰值。

答案2

您可以尝试以下几种方法来获取更多信息：

  • 如果你认为你的服务器已经完全崩溃，你可以从网络控制台如果由于某种原因您无法访问默认控制台。

  • 如果你使用 -p 标志运行 Asterisk，并且它可能正在锁定系统，你可以尝试确保你可以创建一个新的 ssh 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。

相关内容