可能是因为任何内核错误?特别是自旋锁。

Question

我们在英特尔(R) Xeon(R) CPU E5620 @ 2.40GHz上运行带有2.6.38-13通用内核的ubuntu11.04，带有48 GB RAM专用服务器和硬件RAID。

top命令输出显示了运行在不同内核上的许多内核线程。

螺纹数

• ksoftirqd - 16 (每个核心一个)
• kworker - 35
• 移徙- 16人(每个核心一人)

我们已经经历了两次冻结并被迫重新启动机器，这两次都发生在我们修改了.htaccess，然后重新加载了apache之后。

在syslog上，一般保护故障是记录的最后一条消息。

重新启动后，hardisk上的大多数数据变为0字节。2.5 Gb数据在重新启动后很快更改为30 Mb。:(

这是因为任何内核错误。在kernel.org上，2.6.38-13没有被列为稳定的release.Does，这意味着我们需要从当前的内核更改为稳定的内核吗？如果是这样，我们应该选择哪个内核？

syslog输出

这不是内核自旋锁的情况吗？

5月2日22:34:01 416831 CRON19206：(root) CMD (bash /home/admin/log-子)

5月2日22:34:11 416831内核：3715446.033031通用保护故障: 0000 #1 SMP

5月2日22:34:11内核: /sys/devices/system/cpu/cpu15/cache/index2/shared_cpu_map：3715446.054726最后一个sysfs文件

5月2日22:34:11 416831内核：3715446.097404 CPU 5

5月2日22:34:11 416831内核：3715446.097869模块链接在: nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_LOG xt_tcpudp ipt_REDIRECT xt_conntrack iptable_mangle nf_conntrack_ftp ipt_REJECT ipt_LOG xt_multiport xt_state ip6table_filter ip6_tables ip6table_filter ip6_tables in 20 en22 vesafb en25# psmouse ioatdma en27 lp中hed joydev snd_pcm serio_raw parport snd_timer和snd_page_alloc usbhid e1000e

5月2日22:34:11 416831内核：3715446.279465

5月2日22:34:11 416831内核：3715446.303429 Pid: 19118，comm: apache2无污染2.6.38-13-通用#56-UbuntuSupermicroX8DTL/X8DTL

5月2日22:34:11 416831内核：3715446.355544 RIP: 0010:undefined任务_rq_lock+0x4a/0xa0

5月2日22:34:11 416831内核：3715446.411635 RSP: 0018:ffff88060b853da8

5月2日22:34:11 416831内核：3715446.440241 RAX: 010021b86505c7ff RCX: 0000000000013d00rcx: 00000001162d8937

5月2日22:34:11 416831内核：3715446.497492 RDX: 0000000000000282 RSI: ffff88060b853df0 RDI: 00007fdac0088280

5月2日22:34:11 416831内核：3715446.559362 RBP: ffff88060b853dc8 R08: 0000000000000040 R09: 001fc000000000

5月2日22:34:11 416831内核：3715446.625144 R10: 0000000000000000 R11: dead000000100100 R12: 00007fdac0088280

内核：3715446.695569 R13: ffff88060b853df0 R14: 0000000000013d00 R15: 0000000000000005

5月2日22:34:11 416831内核：3715446.770654 FS: 00007fdac0023760(0000) GS:ffff880c3fc20000(0000)

5月2日22:34:11 416831内核：3715446.849786 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

5月2日22:34:11 416831内核：3715446.889882 CR2: 00007fdac187ca80 CR3: 000000058cda1000 CR4: 00000000000006e0

5月2日22:34:11 416831内核：3715446.968627 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000

5月2日22:34:11 416831内核：3715447.049676 DR3: 0000000000000000 DR6: 00000000ff0ff0 DR7: 000000000000000400

5月2日22:34:11 416831内核：3715447.130842进程apache2 (pid: 19118，线程信息ffff88060b852000，任务ffff88058c11c4a0)

5月2日22:34:11 416831内核：3715447.212160堆栈：

5月2日22:34:11 416831内核：3715447.251311 00007fdac0088280 ffff880be1ca5ec8 0000000000000f 0000000000000000

5月2日22:34:11 416831内核：3715447.331017 ffff88060b853e28 ffffffff8105f2e1 0000000000000000 0000000081a4c270

5月2日22:34:11 416831内核：3715447.412179 ffff88060b853e38 0000000000000282 0000000000000021 ffff880b92505ec8

5月2日22:34:11 416831内核：3715447.493302调用跟踪：

5月2日22:34:11 416831内核：3715447.533014 try_to_wake_up+0x31/0x3e0

5月2日22:34:11 416831内核：3715447.573262唤醒_process+0x15/0x20

5月2日22:34:11 416831内核：3715447.612669唤醒_sem_queue_do+0x37/0x60

5月2日22:34:11 416831内核：3715447.651327 freeary+0x1c6/0x200

5月2日22:34:11 416831内核：3715447.689083 semctl_0xbb.clone.5+0xbb/0x110

5月2日22:34:11 416831内核：3715447.726360？+0x7e/0x90

5月2日22:34:11 416831内核：3715447.762833？+0x25/0x30

5月2日22:34:11 416831内核：3715447.798362 sys_semctl+0x7e/0xd0

5月2日22:34:11 416831内核：3715447.833126 system_call_fastpath+0x16/0x1b

5月2日22: 34 :11 416831内核：3715447.867350代码:0048 c7 c3 00 3d 01 00 49 89 fc 49 89 f5 9c 58 0f 1 f 44 00 48 c2 fa 66 0f 1 f 44 00 49 49 55 00 49 8b 44 24 49 89 de <8b> 40 18 4c 03 34 c5 80 c8 81 4c 89 f7 e8 53 4e 57 49 8b 49 8b

5月2日22:34:11 416831内核：3715447.970388 RIP [] task_lock+0x4a/0xa0

5月2日22:34:11 416831内核：3715448.004042 RSP

5月2日22:34:11 416831内核：3715448.083219 -终迹244a1ec2d6f912fa

5月2日22:35:01 416831 CRON19243：(root) CMD (bash /home/admin/log-子)

Answer 1

这听起来像是个硬件缺陷。今天的Linux没有严重程度的bugs -“我重新加载了Apache，服务器崩溃了，数据丢失了”--你有某种硬件问题。过热，内存/CPU/主板/RAID控制器/HDD/其他。

你的帖子被否决的原因是你的帖子缺乏细节。我们不可能猜出出了什么问题(除了我对HW问题的猜测)。

Answer 2

这不太可能是因为一个内核错误。正如Janne所说，硬件故障更有可能发生。您最快的补救方法可能是替换故障硬件，并从备份中重新安装/恢复数据。