死机、宕机、当机?

在不太老的五笔输入法上,这三个词都可以以词组的方式打出来,实际上这三个词都是一个意思。

Linux服务器宕机案例一则,linux案例

案例环境

操作系统 :Oracle Linux Server release 5.7 64bit 虚拟机

硬件配置 : 物理机型号为DELL R720

资源配置 :RAM 8G Intel(R) Xeon(R) CPU E5-2690 8核

案例描述

早晨发现桂林那边一台Linux服务器(虚拟机)网络无法ping通,于是联系那边的系统管理员通过Lync共享桌面给我,通过他的电脑VMware
vSphere
Client登录后,发现在控制台亦无响应。无法登录、无法操作,输入操作无响应。也就是说系统宕机了。没有办法,只能在虚拟机“电源”选项,通过“关闭电源”、“打开电源”选项重启Linux服务器,然后重启了Tomcat服务和Oracle数据库服务。检查了Oracle数据库的告警日志,没有发现任何错误。我的领导通过分析Linux系统日志后,发现在8月1号晚上2:22左右出现,出现内存不足,Linux出于保护机制,把一些无关紧要的进程杀掉。具体错误信息如下所示(服务器名称做了下混淆)

 

Aug  1 01:36:09 G*******LNX01 ntpd[3555]: kernel time sync enabled 4001

Aug  1 01:53:13 G*******LNX01 ntpd[3555]: kernel time sync enabled 0001

Aug  1 02:22:36 G*******LNX01 kernel: hald invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0

Aug  1 02:22:37 G*******LNX01 kernel: hald cpuset=/ mems_allowed=0

Aug  1 02:22:37 G*******LNX01 kernel: Pid: 3408, comm: hald Not tainted 2.6.32-200.13.1.el5uek #1

Aug  1 02:22:37 G*******LNX01 kernel: Call Trace:

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810a0b66>] ? cpuset_print_task_mems_allowed+0x92/0x9e

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810d9ae6>] oom_kill_process+0x85/0x25b

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810d9fbc>] ? select_bad_process+0xbc/0x102

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810da03f>] __out_of_memory+0x3d/0x86

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810da30f>] out_of_memory+0xfc/0x195

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810dd75e>] __alloc_pages_nodemask+0x487/0x595

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff811075ac>] alloc_page_vma+0xb9/0xc8

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810ff0a7>] read_swap_cache_async+0x52/0xf1

Aug  1 02:22:37 G*******LNX01 kernel:  [<ffffffff810ff1a3>] swapin_readahead+0x5d/0x9c

Aug  1 02:22:38 G*******LNX01 kernel:  [<ffffffff810d725a>] ? find_get_page+0x22/0x69

Aug  1 02:22:38 G*******LNX01 kernel:  [<ffffffff810f1ea3>] handle_mm_fault+0x44b/0x80f

Aug  1 02:22:40 G*******LNX01 kernel:  [<ffffffff81043696>] ? should_resched+0xe/0x2f

Aug  1 02:22:40 G*******LNX01 kernel:  [<ffffffff81456006>] do_page_fault+0x210/0x299

Aug  1 02:22:40 G*******LNX01 kernel:  [<ffffffff81453fd5>] page_fault+0x25/0x30

Aug  1 02:22:40 G*******LNX01 kernel: Mem-Info:

Aug  1 02:22:43 G*******LNX01 kernel: Node 0 DMA per-cpu:

Aug  1 02:22:44 G*******LNX01 kernel: CPU    0: hi:    0, btch:   1 usd:   0

Aug  1 02:22:44 G*******LNX01 kernel: CPU    1: hi:    0, btch:   1 usd:   0

Aug  1 08:51:04 G*******LNX01 syslogd 1.4.1: restart.

Aug  1 08:51:04 G*******LNX01 kernel: klogd 1.4.1, log source = /proc/kmsg started.

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys cpuset

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys cpu

 

OOM Killer,说白了 OOM Killer
就是一层保护机制,用于避免在内存不足的时候不至于出现严重问题,把一些无关的进程优先杀掉,即在内存严重不足时,系统为了继续运转,内核会挑选一个进程,将其杀掉,以释放内存,缓解内存不足情况,不过这种保护是有限的,不能完全的保护进程的运行。

但是这个时间点是发生在凌晨2点多,于是我继续检查/var/log/messages日志信息,发现系统启动时出现了

“Phoenix BIOS detected: BIOS may corrupt low RAM, working around
it”错误。于是google搜索这个错误信息。

Aug  1 08:51:04 G*******LNX01 syslogd 1.4.1: restart.

Aug  1 08:51:04 G*******LNX01 kernel: klogd 1.4.1, log source = /proc/kmsg started.

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys cpuset

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys cpu

Aug  1 08:51:04 G*******LNX01 kernel: Linux version 2.6.32-200.13.1.el5uek ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Wed Jul 27 2

1:02:33 EDT 2011

Aug  1 08:51:04 G*******LNX01 kernel: Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet

Aug  1 08:51:04 G*******LNX01 kernel: KERNEL supported cpus:

Aug  1 08:51:04 G*******LNX01 kernel:   Intel GenuineIntel

Aug  1 08:51:04 G*******LNX01 kernel:   AMD AuthenticAMD

Aug  1 08:51:04 G*******LNX01 kernel:   Centaur CentaurHauls

Aug  1 08:51:04 G*******LNX01 kernel: BIOS-provided physical RAM map:

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 0000000000100000 - 00000000bfee0000 (usable)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000bfee0000 - 00000000bfeff000 (ACPI data)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000bfeff000 - 00000000bff00000 (ACPI NVS)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000bff00000 - 00000000c0000000 (usable)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)

Aug  1 08:51:04 G*******LNX01 kernel:  BIOS-e820: 0000000100000000 - 0000000240000000 (usable)

Aug  1 08:51:04 G*******LNX01 kernel: DMI present.

Aug  1 08:51:04 G*******LNX01 kernel: Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.

Aug  1 08:51:04 G*******LNX01 kernel: last_pfn = 0x240000 max_arch_pfn = 0x400000000

Aug  1 08:51:04 G*******LNX01 kernel: x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106

Aug  1 08:51:04 G*******LNX01 kernel: total RAM covered: 8192M

Aug  1 08:51:04 G*******LNX01 kernel: Found optimal setting for mtrr clean up

Aug  1 08:51:04 G*******LNX01 kernel:  gran_size: 64K  chunk_size: 64K         num_reg: 4      lose cover RAM: 0G

Aug  1 08:51:04 G*******LNX01 kernel: x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106

Aug  1 08:51:04 G*******LNX01 kernel: last_pfn = 0xc0000 max_arch_pfn = 0x400000000

Aug  1 08:51:04 G*******LNX01 kernel: init_memory_mapping: 0000000000000000-00000000c0000000

Aug  1 08:51:04 G*******LNX01 kernel: init_memory_mapping: 0000000100000000-0000000240000000

Aug  1 08:51:04 G*******LNX01 kernel: RAMDISK: 37c4d000 - 37fef894

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: RSDP 00000000000f6940 00024 (v02 PTLTD )

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: XSDT 00000000bfeefddc 0005C (v01 INTEL  440BX    06040000 VMW  01324272)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: FACP 00000000bfefee98 000F4 (v04 INTEL  440BX    06040000 PTL  000F4240)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: DSDT 00000000bfef0230 0EC68 (v01 PTLTD  Custom   06040000 MSFT 03000001)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: FACS 00000000bfefffc0 00040

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: BOOT 00000000bfef0208 00028 (v01 PTLTD  $SBFTBL$ 06040000  LTP 00000001)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: APIC 00000000bfef0156 000B2 (v01 PTLTD  ? APIC   06040000  LTP 00000000)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: MCFG 00000000bfef011a 0003C (v01 PTLTD  $PCITBL$ 06040000  LTP 00000001)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: SRAT 00000000bfeefed8 00128 (v02 VMWARE MEMPLUG  06040000 VMW  00000001)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: HPET 00000000bfeefea0 00038 (v01 VMWARE VMW HPET 06040000 VMW  00000001)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: WAET 00000000bfeefe78 00028 (v01 VMWARE VMW WAET 06040000 VMW  00000001)

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 0 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 1 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 2 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 3 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 4 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 5 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 6 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: PXM 0 -> APIC 7 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: Node 0 PXM 0 0-a0000

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: Node 0 PXM 0 100000-c0000000

Aug  1 08:51:04 G*******LNX01 kernel: SRAT: Node 0 PXM 0 100000000-240000000

Aug  1 08:51:04 G*******LNX01 kernel: Bootmem setup node 0 0000000000000000-0000000240000000

Aug  1 08:51:04 G*******LNX01 kernel:   NODE_DATA [000000000001b840 - 000000000003183f]

Aug  1 08:51:04 G*******LNX01 kernel:   bootmap [0000000000032000 -  0000000000079fff] pages 48

Aug  1 08:51:04 G*******LNX01 kernel: (9 early reservations) ==> bootmem [0000000000 - 0240000000]

Aug  1 08:51:04 G*******LNX01 kernel:   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]

Aug  1 08:51:04 G*******LNX01 kernel:   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]

Aug  1 08:51:04 G*******LNX01 kernel:   #2 [0001000000 - 000224b73c]    TEXT DATA BSS ==> [0001000000 - 000224b73c]

Aug  1 08:51:04 G*******LNX01 kernel:   #3 [0037c4d000 - 0037fef894]          RAMDISK ==> [0037c4d000 - 0037fef894]

Aug  1 08:51:04 G*******LNX01 kernel:   #4 [000009f800 - 0000100000]    BIOS reserved ==> [000009f800 - 0000100000]

Aug  1 08:51:04 G*******LNX01 kernel:   #5 [000224c000 - 000224c1e8]              BRK ==> [000224c000 - 000224c1e8]

Aug  1 08:51:04 G*******LNX01 kernel:   #6 [0000010000 - 0000012000]          PGTABLE ==> [0000010000 - 0000012000]

Aug  1 08:51:04 G*******LNX01 kernel:   #7 [0000012000 - 0000017000]          PGTABLE ==> [0000012000 - 0000017000]

Aug  1 08:51:04 G*******LNX01 kernel:   #8 [0000017000 - 000001b840]       MEMNODEMAP ==> [0000017000 - 000001b840]

Aug  1 08:51:04 G*******LNX01 kernel: found SMP MP-table at [ffff8800000f69b0] f69b0

Aug  1 08:51:04 G*******LNX01 kernel: Zone PFN ranges:

Aug  1 08:51:04 G*******LNX01 kernel:   DMA      0x00000010 -> 0x00001000

Aug  1 08:51:04 G*******LNX01 kernel:   DMA32    0x00001000 -> 0x00100000

Aug  1 08:51:04 G*******LNX01 kernel:   Normal   0x00100000 -> 0x00240000

Aug  1 08:51:04 G*******LNX01 kernel: Movable zone start PFN for each node

Aug  1 08:51:04 G*******LNX01 kernel: early_node_map[4] active PFN ranges

Aug  1 08:51:04 G*******LNX01 kernel:     0: 0x00000010 -> 0x0000009f

Aug  1 08:51:04 G*******LNX01 kernel:     0: 0x00000100 -> 0x000bfee0

Aug  1 08:51:04 G*******LNX01 kernel:     0: 0x000bff00 -> 0x000c0000

Aug  1 08:51:04 G*******LNX01 kernel:     0: 0x00100000 -> 0x00240000

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: PM-Timer IO Port: 0x1008

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled)

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])

Aug  1 08:51:04 G*******LNX01 kernel: IOAPIC[0]: apic_id 8, version 17, address 0xfec00000, GSI 0-23

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)

Aug  1 08:51:04 G*******LNX01 kernel: Using ACPI (MADT) for SMP configuration information

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: HPET id: 0x8086af01 base: 0xfed00000

Aug  1 08:51:04 G*******LNX01 kernel: SMP: Allowing 8 CPUs, 0 hotplug CPUs

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 000000000009f000 - 00000000000a0000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000000a0000 - 00000000000ca000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000000ca000 - 00000000000cc000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000000cc000 - 00000000000dc000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000000dc000 - 0000000000100000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000bfee0000 - 00000000bfeff000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000bfeff000 - 00000000bff00000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000c0000000 - 00000000e0000000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000fec00000 - 00000000fec10000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000fec10000 - 00000000fee00000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000fee01000 - 00000000fffe0000

Aug  1 08:51:04 G*******LNX01 kernel: PM: Registered nosave memory: 00000000fffe0000 - 0000000100000000

Aug  1 08:51:04 G*******LNX01 kernel: Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)

Aug  1 08:51:04 G*******LNX01 kernel: Booting paravirtualized kernel on bare hardware

Aug  1 08:51:04 G*******LNX01 kernel: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1

Aug  1 08:51:04 G*******LNX01 kernel: PERCPU: Embedded 29 pages/cpu @ffff880028200000 s88280 r8192 d22312 u262144

Aug  1 08:51:04 G*******LNX01 kernel: pcpu-alloc: s88280 r8192 d22312 u262144 alloc=1*2097152

Aug  1 08:51:04 G*******LNX01 kernel: pcpu-alloc: [0] 0 1 2 3 4 5 6 7 

Aug  1 08:51:04 G*******LNX01 kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2064641

Aug  1 08:51:04 G*******LNX01 kernel: Policy zone: Normal

Aug  1 08:51:04 G*******LNX01 kernel: Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet

Aug  1 08:51:04 G*******LNX01 kernel: PID hash table entries: 4096 (order: 3, 32768 bytes)

Aug  1 08:51:04 G*******LNX01 kernel: Initializing CPU#0

Aug  1 08:51:04 G*******LNX01 kernel: xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340

Aug  1 08:51:04 G*******LNX01 kernel: Checking aperture...

Aug  1 08:51:04 G*******LNX01 kernel: No AGP bridge found

Aug  1 08:51:04 G*******LNX01 kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

Aug  1 08:51:04 G*******LNX01 kernel: Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000

Aug  1 08:51:04 G*******LNX01 kernel: software IO TLB at phys 0x20000000 - 0x24000000

Aug  1 08:51:04 G*******LNX01 kernel: Memory: 8183576k/9437184k available (4454k kernel code, 1049156k absent, 204452k reserved, 7191k data, 1720k init)

Aug  1 08:51:04 G*******LNX01 kernel: Hierarchical RCU implementation.

Aug  1 08:51:04 G*******LNX01 kernel: NR_IRQS:4352 nr_irqs:472

Aug  1 08:51:04 G*******LNX01 kernel: Extended CMOS year: 2000

Aug  1 08:51:04 G*******LNX01 kernel: Console: colour VGA+ 80x25

Aug  1 08:51:04 G*******LNX01 kernel: console [tty0] enabled

Aug  1 08:51:04 G*******LNX01 kernel: allocated 83886080 bytes of page_cgroup

Aug  1 08:51:04 G*******LNX01 kernel: please try 'cgroup_disable=memory' option if you don't want memory cgroups

Aug  1 08:51:04 G*******LNX01 kernel: TSC freq read from hypervisor : 2900.001 MHz

Aug  1 08:51:04 G*******LNX01 kernel: Detected 2900.001 MHz processor.

Aug  1 08:51:04 G*******LNX01 kernel: Calibrating delay loop (skipped) preset value.. 5800.00 BogoMIPS (lpj=2900001)

Aug  1 08:51:04 G*******LNX01 kernel: Security Framework initialized

Aug  1 08:51:04 G*******LNX01 kernel: SELinux:  Initializing.

Aug  1 08:51:04 G*******LNX01 kernel: Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)

Aug  1 08:51:04 G*******LNX01 kernel: Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)

Aug  1 08:51:04 G*******LNX01 kernel: Mount-cache hash table entries: 256

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys ns

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys cpuacct

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys memory

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys devices

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys freezer

Aug  1 08:51:04 G*******LNX01 kernel: Initializing cgroup subsys net_cls

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Physical Processor ID: 0

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Processor Core ID: 0

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L1 I cache: 32K, L1 D cache: 32K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L2 cache: 256K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L3 cache: 20480K

Aug  1 08:51:04 G*******LNX01 kernel: CPU 0/0x0 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: mce: CPU supports 0 MCE banks

Aug  1 08:51:04 G*******LNX01 kernel: Performance Events: Nehalem/Corei7 events, Intel PMU driver.

Aug  1 08:51:04 G*******LNX01 kernel: ... version:                3

Aug  1 08:51:04 G*******LNX01 kernel: ... bit width:              48

Aug  1 08:51:04 G*******LNX01 kernel: ... generic registers:      4

Aug  1 08:51:04 G*******LNX01 kernel: ... value mask:             0000ffffffffffff

Aug  1 08:51:04 G*******LNX01 kernel: ... max period:             000000007fffffff

Aug  1 08:51:04 G*******LNX01 kernel: ... fixed-purpose events:   3

Aug  1 08:51:04 G*******LNX01 kernel: ... event mask:             000000070000000f

Aug  1 08:51:04 G*******LNX01 kernel: ACPI: Core revision 20090903

Aug  1 08:51:04 G*******LNX01 kernel: ftrace: converting mcount calls to 0f 1f 44 00 00

Aug  1 08:51:04 G*******LNX01 kernel: ftrace: allocating 26665 entries in 105 pages

Aug  1 08:51:04 G*******LNX01 kernel: Setting APIC routing to flat

Aug  1 08:51:04 G*******LNX01 kernel: ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1

Aug  1 08:51:04 G*******LNX01 kernel: CPU0: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping 07

Aug  1 08:51:04 G*******LNX01 kernel: Booting processor 1 APIC 0x1 ip 0x6000

Aug  1 08:51:04 G*******LNX01 kernel: Initializing CPU#1

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Physical Processor ID: 0

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Processor Core ID: 1

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L1 I cache: 32K, L1 D cache: 32K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L2 cache: 256K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L3 cache: 20480K

Aug  1 08:51:04 G*******LNX01 kernel: CPU 1/0x1 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: mce: CPU supports 0 MCE banks

Aug  1 08:51:04 G*******LNX01 kernel: CPU1: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping 07

Aug  1 08:51:04 G*******LNX01 kernel: Skipping synchronization checks as TSC is reliable.

Aug  1 08:51:04 G*******LNX01 kernel: Booting processor 2 APIC 0x2 ip 0x6000

Aug  1 08:51:04 G*******LNX01 kernel: Initializing CPU#2

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Physical Processor ID: 1

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Processor Core ID: 0

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L1 I cache: 32K, L1 D cache: 32K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L2 cache: 256K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L3 cache: 20480K

Aug  1 08:51:04 G*******LNX01 kernel: CPU 2/0x2 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: mce: CPU supports 0 MCE banks

Aug  1 08:51:04 G*******LNX01 kernel: CPU2: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping 07

Aug  1 08:51:04 G*******LNX01 kernel: Booting processor 3 APIC 0x3 ip 0x6000

Aug  1 08:51:04 G*******LNX01 kernel: Initializing CPU#3

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Physical Processor ID: 1

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Processor Core ID: 1

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L1 I cache: 32K, L1 D cache: 32K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L2 cache: 256K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L3 cache: 20480K

Aug  1 08:51:04 G*******LNX01 kernel: CPU 3/0x3 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: mce: CPU supports 0 MCE banks

Aug  1 08:51:04 G*******LNX01 kernel: CPU3: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping 07

Aug  1 08:51:04 G*******LNX01 kernel: Booting processor 4 APIC 0x4 ip 0x6000

Aug  1 08:51:04 G*******LNX01 kernel: Initializing CPU#4

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Physical Processor ID: 2

Aug  1 08:51:04 G*******LNX01 kernel: CPU: Processor Core ID: 0

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L1 I cache: 32K, L1 D cache: 32K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L2 cache: 256K

Aug  1 08:51:04 G*******LNX01 kernel: CPU: L3 cache: 20480K

Aug  1 08:51:04 G*******LNX01 kernel: CPU 4/0x4 -> Node 0

Aug  1 08:51:04 G*******LNX01 kernel: mce: CPU supports 0 MCE banks

Aug  1 08:51:04 G*******LNX01 kernel: CPU4: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping 07

--More--(17%)

搜索了很多资料,等我还在茫茫大海中苦苦查证时,又连接不上该服务器,该服务器又宕机了。由于没有权限,Lync共享桌面又奇慢无比。求助于我们这边的系统管理员(拥有那边的虚拟机服务器权限),他用vSphere
Client连接上去检查时,终于发现一个让人既郁闷又震惊的原因。

这台物理机DELL
R720只有32G内存,上面有一个Linux系统、几个Windows系统。但是有于那边管理员添加了测试服务器,所有系统总共分配的内存加起来43G已经超过了原来物理机32G内存,导致系统间资源争用。出现内存资源不足的情况。最后Linux直接宕机的情况。

出现这种情况,一来是由于管理员疏忽,没有注意到实际内存资源分配情况。二来我不知情,信息不足(由于权限问题,我并不了解那边物理机与虚拟机的情况),一直运行的好好的系统,突然出现这个问题,导致我局限在数据库、应用程序、操作系统层面去查找原因。而没有纵览全局,从架构、资源层面去查找问题。导致一直没有查找到根本原因之所在。

 

解决方案

关闭测试服务器,释放出足够的内存资源。问题解决。然后系统从8月1号运行到现在再也没有出现过这个问题。

 

参考资料:

 

社区有很多兄弟分享惨痛宕机案例,提醒大家需警惕,以下介绍几起,满满都是血的教训……

“死机”就是我们平常白话说的了:移动鼠标系统没响应、键盘输入系统没响应……。

1linux服务器突然宕机你的反映是什?应该怎做? 2运维工程师们在你的工作总遇到的最大问题是什?

我的处理方式:
1、领导报告
2、服务宕机/服务器宕机
3、远程登录查看服务,重启相关/让机房人员重启服务器
4、根据以上再做决定
数据永远是最大的
 

1.AIX 下 NTP 设置不当导致的多个集群宕机

“宕机”是应该是港台的写法,从英文 down 译过来(英文里面down、crash、hang
等都可以形容宕机),就好像“酷”来源于 cool 一样。“宕”有搁置的意思。

linux系统每天宕机一次,重器一段时间后才可以恢复,跪原因、帮助?

  1. 建议你到/var/log中看看日志,重点分析一下messages和secure

  2. 观察一段时间内负载的变化情况

  3. 安装一个RKHunter查一查,看看是否中招了
     

案例环境
操作系统 : Oracle Linux Server release 5.7 64bit 虚拟机 硬件配置 :
物理机型号为DELL R720 资源配置…

事情发生在一段时间之前,接到朋友电话,用户有三套 oracle rac 集群运行在
aix
小机上,本地两套,同城机房两套,做完设备搬迁后的一天晚上,其中本地和同城的两套
rac 突然就整个重启了,而且发生在同一时间点。

“当机”在内地用得比较多,在 Google 上搜索“当机”结果也要多于“宕机”。

网络、小机、存储、数据库分属不同的维保厂商,这就开始了扯皮。各家就开始从自己的方向自证无过错。我去之前内心也比较倾向于
oracle 的网络心跳出了问题,crs 抢 vote disk
的时候触发了重启。但由于是小机方的代表,仅从 aix
层面做了排查,未发现明显原因。对各主机宕机的时间做了一个梳理,去和
oracle 的事件日志去比对。暂时没查到什么东西。

宕机产生的 dump 发到了 IBM 原厂,IBM 后来出了个报告,根据 dump
内容定位触发宕机的进程为 cssd。oracle dba
重点看了那个进程的日志,发现宕机时间前后,时间突然变更,提前了40多秒。dba
确认,时间变更过多,cssd 进程会导致系统重启,怀疑和时间同步有关。

经检查,3套 aix 的 rac 集群使用了同一个 ntp
server,但有一套没发生问题。对比检查差异,发现没问题的那套主机集群使用
xntpd 方式配置了时间同步。出问题的主机则直接使用了 ntpdate
命令做时间更新,并写入了 crontab 定期执行。检查 /var/adm/cron/log
日志,发现定时任务的执行时间和 cssd
故障时间一致。检查时间服务器,发现搬迁后,时间服务器的时间产生了较大偏差,xntpd
方式的时间同步在时间偏差大时不会去强制同步,ntpdate
命令的方式没有这个限制,会直接进行同步。最终导致了 cssd
进程检测到过大时间偏差后触发了宕机。

经验分享:配置时间同步时,建议使用 xntpd
服务的方式,
不用直接在定时任务里写 ntpdate,因为 ntpdate
比较粗暴,发生故障时较大的时间偏差会导致应用出现问题,触发无法预知的后果。

由社区会员王巧雷分享

2.采用爱数备份一体机导致宕机

去年我们刚刚入手了一台爱数备份一体机,在测试阶段遇到了一个小例子和大家分享一下:

当时测试各种数据的备份和功能,就在一台系统上安装了爱数备份的代理客户端,客户端安装选项中有一项安装
CDP 驱动。
当时并没有留意,后来升级客户端版本,另外做了一些其他测试,就把代理客户端卸载了,但是并没有先去卸载
CDP
驱动,重启后系统就直接起不来了,和爱数的技术支持沟通后了解,需要先卸载CDP驱动,再卸载客户端,否则
CDP 驱动存在的时候,就会导致系统启动失败。

由社区会员“pysx0503”分享

3.经典双机双存储,某晚主存储异常故障,业务立刻中断

用户经典的双机双存储高可用应用方案。IBM 2*P570 PowerHA6.1
两台中端存储通过 lvm mirror
实现的数据镜像,上面跑着用户信贷系统,报表系统,存储压力较为繁忙。用户每年都会完成一次
HA
切换演练保证业务高可用。某晚一次存储电源故障,电源还没来得急更换,另外一个电源也坏了。这样主存储宕机了。恰巧这个时候业务也立刻停止了,用户电话里说刚做完的
Powerha 的演练,很顺利。可今天发生的这事却百思不得其解。

后来经过大量的日志和与用户交流得知,用户之前的一个操作给这次的业务中断埋下了一个大大的”地雷”。

究竟用户自己做的什么操作导致的此次事件呢?

用户业务系统有一个文件系统存储空间不够了,需要扩容,但是目前共享 vg
里的空间无法满了,需要重新加新的磁盘到 vg
里,存储管理员分配新的磁盘给两台主机,然后用户通过 Powerha cspoc
去加盘,扩容 FS。就是这么一个操作导致的问题发生。

经验分享:lvm mirror 双存储的情况下,我们扩 fs 需要注意先扩 LV,再扩
fs,这样能保证数据正确分布在2个存储上,
如果在用户这种场景新加磁盘后直接扩fs,那就会造成数据拷贝是2份,但是不能准确地保证分布在两个存储上,有可能存储A分布90%
存储B分布110%。这样一台存储故障,就会直接导致数据的不完整。

由社区会员孙伟光分享

4.HACMP NODE ID 一致导致故障宕机

故障描述:

前些天在论坛闲逛,发现一兄弟的帖子“Power HA
其中一台异常宕机”,点进去一看,发现故障描述和报错信息和我之前遇到的完全一样,基于提醒和血的教训,特将该问题编写成案例,希望大家引以为戒!

我们生产环境有 PowerVM 虚拟化后的 AIX 虚拟机2台,灾备环境有 PowerVM
虚拟化后 AIX 虚拟机1台,三台虚拟机通过 PowerHA XD(基于 SVC PPRC
远程复制)搭建了跨中心高可用环境,操作系统版本为7.1.2.3,HA
版本为7.1.2.6,搭建该环境之前,生产环境的两台 AIX 是通过 HAMCP
搭建了本地的高可用环境,为了灾备建设需求,将本地的1台主机通过
alt_disk_copy 的方式复制了一份 rootvg 至外置存储,并将该外置存储通过
SVC PPRC
复制至灾备存储卷当中,灾备的虚拟机再挂载该卷,并通过该卷启动操作系统。这样三台
AIX 虚拟机再重新搭建了PowerHA XD,实现跨中心 HA 热备。

通过这种方式,我们搭建了三套系统,均通过了 HA
切换测试,但是运行了一段时间后,其中一套系统的主机故障宕机,资源组切向了备机,发现问题后,第一时间查看
errpt 日志,如下

故障分析:

由于操作系统没有开 always allow dump,所以并没有产生 dump
文件,当时分析了很久日志,很是疑惑不解,最终只能提交给 IBM
后台进行分析,后台也是许多天都没有答复。过了一个星期后,第二套系统也出现了一样的现象,一样的故障,造成主备
HA 切换,我开始怀疑是 HACMP XD
实施问题,立马翻阅了一下实施文档,发现在做 alt_disk_copy 时只用了
alt_disk_copy -d hdiskx,后面并没有用-O -B
-C参数,这些参数主要是用来复制rootvg时,删除原操作系统的配置信息和 ODM
库的一些信息,这样一来可能就会造成生产主机和灾备备机的操作系统某些信息一致。基于这种怀疑,我复看了
errpt 报错记录,宕机的主要原因应该是以下几个点:

IBM.StorageRM daemon has been stopped

Group Services daemon stopped

Group Services detected a failure

QUORUM LOST,VOLUME GROUP GROUP CLOSING

猜想是否是 QUORUM 中保留的两个主备节点信息一致,导致 QUORUM 关闭。

接着在生产主机运行命令

odmget -q attribute=node_uuid’ CuAt

输出:CuAt: name = cluster0 attribute = node_uuid value =
673018b0-7a70-11e5-91fa-f9fe9b9bc3c6 type = R generic = DU rep = s
nls_index = 3

在灾备主机运行命令 odmget -q attribute=node_uuid’ CuAt

输出:CuAt: name = cluster0 attribute = node_uuid value =
67301842-7a70-11e5-91fa-f9fe9b9bc3c6 type = R generic = DU rep = s
nls_index = 3

生产主机运行命令

/usr/sbin/rsct/bin/lsnodeid

灾备主机运行命令

/usr/sbin/rsct/bin/lsnodeid

以上发现两个节点的 RSCT NODE ID 完全一致

这就是造成信息冲突的点,造成了主服务停止和 QUORUM 仲裁关闭的元凶。

故障解决:

1.将 PowerHA XD 的 HA 服务全部关闭,禁止 HA 组服务的保护,并运行命令

/usr/sbin/rsct/bin/hags_stopdms -s cthags

/usr/sbin/rsct/bin/hags_disable_client_kill -s cthags

2.停止 HA 的 ConfigRM 服务和 cthags 服务

stopsrc -s IBM.ConfigRM stopsrc -s cthags

3.重新配置 RSCT 节点

/usr/sbin/rsct/install/bin/recfgct

4.重启所有3台操作系统

shutdown -Fr

5.启动 HACMP 服务和资源组,并检查 RSCT NODE ID

经验分享:通过以上方法,彻底解决了三套系统的 HACMP
主机宕机问题,建议以后做类似 alt_disk_copy 时,一定要带上-B -C
-O参数,保持新操作系统的洁净,
以防碰到类似的莫名其妙的问题。

由社区会员“jxnxsdengyu”分享

5.Power 570/595 宕机

事情起因:

由于机器宕机是在周六,是客户的核心应用,但周六客户没有人上班,当周一上班的时候发现所有的办公,邮件系统等一半的核心应用不能访问,经过现场机房管理人员的临时排查,发现小机
Power595 后面所有的 I/O 柜掉电,Power570 黄灯亮起,绿灯慢闪。

工程师到达现场,按照与客户沟通好结果,我们开始干活,大概折腾了6个小时,Power595
还是没有启动起来,但 power570
可以正常访问了。为了赶紧让客户生产数据,我们临时决定,用 power570
临时做个 lpar
让存储链接过来,先拉起应用,再又折腾了3个多小时之后,所有应用都可以正常访问。我们继续排查Power595,我们更换了
CEC DCA 内存板,CPU 都没有解决问题,最后更换了 pubook
问题解决了,花费时间3天。

问题原因:

电工改造线路,造成了机房断电,UPS
临时接管,由于电池放了太久,机器功率太大,造成低电压运行,造成设备不能正常工作,更为关键的是电工出现问题之后没有及时检查电路,根据师傅的陈述大概过了1分钟又把交流电送出去,这个电压冲击是很厉害的,经排查此电工无证施工,客户已经提起诉讼。

由社区会员“shizhe1030”分享

6.ERP 备份导致的一起宕机案例

现象回顾:

某日凌晨,其中一台 ERP 数据库主机宕机。AIX.5.3 HACMP RAC 数据库环境。

故障分析:

宕机时间点是在备份期间。通过分析数据库日志、系统日志、发现导致数据库停库的主要原因是由于
HACMP 的一个守护进程 haemd 发生自动重启,由于 oracle 数据库和 haemd
进程之间有关联,因此数据库在发现 haemd 重新启动后也自动停止。

经 IBM 工程师及实验室分析,Haemd
自动重新启动的原因是由于在一定期间内没有给 HACMP
系统响应,其原因之一是由于系统过于繁忙,没有响应 Haemd。

随后分析结果发现在备份期间,从存储看系统不是很繁忙;但 ERP
数据库服务器主机性能异常:有时会出现阶段性的不响应现象,同时系统 I/O
高。停止备份后,这种现象消失。

经 IBM 实验室协助,初步经过分析:

1)AIX
系统内存分为计算类和非计算类内存。非计算类内存主要用于文件操作CACHE,以便提高文件再次读写的性能。目前
ERP 生产数据库占用了近20G内存作为文件系统 CACHE。

2)当文件系统 CACHE 有空间时,写文件操作将不会产生阻塞,当文件系统 CACHE
无空间时,系统将会根据内部策略,挤出部分 CACHE。当无法找到空闲的 CACHE
时,会等待系统调整出空闲的
CACHE。当出现大量等待时,系统可能出现无响应的状态。

解决方案:

考虑到将来数据量的增加,如果无法解决较大 I/O
对系统的影响过大的问题,这个隐患将一直存在。

调整该备份文件系统的属性,在该文件系统的 I/O
请求到达一定值的情况下,阻塞对该文件系统的读写
I/O,从而保证预留足够的资源给系统。具体参数为 Maxpout、Minpout。

经验分享:Maxpout、Minpout
参数的选择,是和具体环境相关的,没有一个统一的建议值。若该参数设置不合理,可能会影响到文件系统的读写操作。而合适的参数需要经过设置、观察来确定。

由社区会员孙伟光分享

7.weblogic 宕机问题排查

问题现象:

系统持续运行2-3天,中间件出现宕机

系统运行期间只要访问 weblogic 控制台,操作几次后中间件宕机

报错日志:

分析:

通过报错日志分析,为内存溢出,且为非堆内存溢出,这种情况一般需要调整:PermSize
的大小。

解决过程:

调整 weblogic 配置参数:setDomainEnv.sh 设置 setDomainEnv.sh 为512。

调整后重启系统,发现问题依旧,并没有解决宕机问题。

确认修改参数是否生效:生成 javacore 来分析截图如下:

我们发现参数并没有生效。继续分析参数为什么没有生效。

Weblogic 中的 commEnv.sh ,发现 JAVA_VENDOR 为 N/A

而 setDomainEnv.sh 中 PermSize 的设置为:

此处的参数并没有 设置我们需要的 Open JDK的 JAVA_VENDOR 的 N/A
的赋值,所以非堆内存的设置并未生效。

注意:正常 open jdk 的 JAVA_VENDOR 为 Oracle
的,但是配置文件却为:N/A,可能是 weblogic
的兼容性问题,或者人为改动导致,找到原因了,这个问题就没有细究。

解决方案:

修改 commEnv.sh , JAVA_VENDOR 为 Oracle、HP、IBM、Apple 中的任何一个

在 startWeblogic 中,单独定义:MEM_ARGS=-Xms2048m -Xmx2048m
-XX:PermSize=1024m

验证方案:

采取第二种方案:

1)在原始默认环境,进行12个小时的循环操作,并持续访问 weblogic 控制台。

2)在修改后的环境,持续访问 weblogic 控制台,生成 javacore
文件看参数是否生效。并进行50人高强度的并发测试20个小时,看是否会重现宕机问题。

在方案的第一步,系统运行2小时,访问控制台,中间件宕机,系统无法访问。

在方案的第二步,系统在50人高强度的并发测试20小时的情况下,响应正常。频繁访问控制台并未发现任何异常。通过生成
javacore 发现非堆内存正常生效。

由社区会员“gu y 011”分享

8.P550/P570 宕机案例

某周末,客户致电,说核心业务无法访问。工程师到达现场,发现客户环境P550
两台小机均关机。发现客户现场有部分服务器也已处于关机掉电状态。此时客户才发现,市电周五晚上断电过,但是客户机房配备有2台
UPS,机房设备一半一半分别接到2台 UPS上。排查发现其中一台
UPS无法供电。而两台小机均有一路电源接到该
UPS,导致市电断电后,直接宕机。

后将小机通电开机,发现P550无法开机,CPU VRM
稳压模块报错,由于客户业务较为重要,将 P570 已经拉起来,准备将 HA 集群在
IBM P570 单节点运行。却发现 HA 无法将 Oracle
数据库拉起。由于时间紧迫,手动在 P570 网卡上添加 IP 别名后,手动挂载
VG,恢复业务。

后续,将 P550
稳压模块进行更换后,发现仍然无法开机,又出现新的报错:11002630,再次更换
CPU 板后,P550
小机正常开机。安排停机窗口进行排查恢复。在处理过程中,集群出现意外,在
HA
拉起来后,经业务测试,发现/orafile丢失一部分数据,此时备份数据最新的为前一天晚上23点,单天的数据未做备份,只能采取数据恢复,最后成功将数据恢复回来。重新配置
HA,模拟故障切换,测试业务,验证数据完整性,业务恢复正常!

由社区会员“ACDante”分享

9.AIX6100-06-06系统 bug 引起 down 机

某机器操作系统版本6100-06-06,系统 down 机,生成 dump 文件。

Problem:

System crash with following stack

CRASH INFORMATION:

CPU 3 CSA F00000002FF47600 at time of crash, error code

for

LEDs: 30000000

pvthread+02BD00 STACK:

[00009500].simple_lock+000000 ()

[00450E24]netinfo_unixdomnlist+000824 (??, ??, ??, ??,

??, ??)

[0451214C]netinfo+00006C (??, ??, ??, ??, ??, ??)

[004504DC]netinfo+0000FC (??, ??, ??, ??)

[00003850]ovlya_addr_sc_flih_main+000130 ()

[kdb_get_virtual_memory] no real storage @

FFFFFFFFFFFEF20

[100002640]0000000100002640 ()

[kdb_read_mem] no real storage @ FFFFFFFFFFF5E30

bug原因:

File lock is taken before checking whether the file type is socket.

该故障因 netstat -f unix 命令引起系统 crash, 是 IBM bug 引起

建议单独提升 bos.mp64包补丁包或者整体升级到6100-06-12-1339(SP12)

官网解释:

IV09793: SYSTEM CRASH IN NETINFO_UNIXDOMNLIST APPLIES TO AIX 6100-06

-01.ibm.com/support/docview.wss?uid=isg1IV09793

File lock is taken before checking whether the file type is socket.

由社区会员“qb306”分享

10.P570 宕机案例

IBM 570 意外宕机,处理过程如下:

1、首先查看 asmi
日志,电源和风扇故障,更换了2个电源和1个风扇后,可以启动到 standby
模式。但是非常多的 firmware 报错。

2、升级微码到 sf240-417后,微码报错消失。

3、激活分区失败,hmc 终端会出现几秒的”ide inited
failed“提示,然后消失。接着卡死,报找不到硬盘。

4、观察外观,发现后端的光纤卡灯特别弱,有时会不亮。

5、查了下570的红皮书结构图,发现 ide controller(红线圈住部分)同时处理
pci 设备和硬盘背板设备过来的 io,根据现有故障现象,判定 ide controller
有故障。

6、通过 ibm system information center,定位到 ide controller 的 location
code 为p1-15,不是一个可替换的 FRU,必须随同 IO backbone一起更换。

7、更换 io backbone 后,系统正常启动,进入系统微调后,一切正常。

由社区会员王巧雷分享

11.某企业 HACMP 软件,在网络交换机变更时引起 down 机

某企业 HA cluster log, IP switch down 时引起双节点
halt,系统版本7100-03-03,HA 版本6.1sp13

Error description

In HACMP 6 with rsct.core.utils 3.1.4.9 or higher, if all

IP networks are lost and at least one non-IP network is

functioning, the Group Services subsystem will core dump when

trying to send packets to be routed through Topology Services

(across the non-IP connection). This will cause a node halt.

Customers with PowerHA 7, or HACMP 6 customers with no non-IP

networks (such as rs232 or disk) are not in danger. Also this

will not happen if only one node is still running, since there

will be no other cluster members to send messages to.

日志如下:

原因是补丁 IV55293: HAGSD CORE DUMP WHEN IP NETWORKS LOST, 需要升级
rsct 文件集。

官网解释:

-01.ibm.com/support/docview.wss?uid=isg1IV55293

由社区会员“qb306”分享

12.巡检不仔细 Power595 宕机

事件起因,本来巡检已经发现其中的一个 I/O
柜电源故障,在线更换走脚步的时候,脚步执行到一半引起该 I/O
柜突然掉电,重启了该 I/O 柜。

原因:一线工程师巡检时候不够仔细,因为该同一个 I/O
其实坏了2个电源,只不过另外一个没有报出来具体的位置,但已经报出来该 I/O
的部件号,但也说明了 IBM 小机没有完全报错具体槽位,只报错了大概的位置。

解决方法:设备下电,更换两个 I/O DCA,然后设备开机,问题解决。

由社区会员“shizhe1030”分享

13.X86 史上最离谱的宕机事件

硬件: IBM的X3650 操作系统: suse 9

linux 系统无法远程登陆,用 KVM 登录上去看发现定在操作系统页面不能动。

重启操作系统后,在操作系统 message 日志里面查看到如下错误:

经过咨询 novell 和 IBM 工程师,结论是 IBM 这类服务器在装 linux
系统的时候,如果光驱有问题确实是会导致宕机。

经硬件工程师检查,是光驱坏了……坏了……

编者按:宕机原因千万种,这个宕机有点冤

由社区会员“hp_hp”分享

发表评论

电子邮件地址不会被公开。 必填项已用*标注