DELL R410服务器宕机案例(3)

简介:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
我的博客已迁移到xdoujiang.com请去那边和我交流
Apr 20 16:20:06 10.1.1.1 DMA32: 
Apr 20 16:20:06 10.1.1.1 1*4kB 
Apr 20 16:20:06 10.1.1.1 0*8kB 
Apr 20 16:20:06 10.1.1.1 1*16kB 
Apr 20 16:20:06 10.1.1.1 0*32kB 
Apr 20 16:20:06 10.1.1.1 2*64kB 
Apr 20 16:20:06 10.1.1.1 0*128kB 
Apr 20 16:20:06 10.1.1.1 0*256kB 
Apr 20 16:20:06 10.1.1.1 0*512kB 
Apr 20 16:20:06 10.1.1.1 1*1024kB 
Apr 20 16:20:06 10.1.1.1 1*2048kB 
Apr 20 16:20:06 10.1.1.1 5*4096kB 
Apr 20 16:20:06 10.1.1.1 = 23700kB
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 Normal: 
Apr 20 16:20:06 10.1.1.1 0*4kB 
Apr 20 16:20:06 10.1.1.1 0*8kB 
Apr 20 16:20:06 10.1.1.1 0*16kB 
Apr 20 16:20:06 10.1.1.1 1*32kB 
Apr 20 16:20:06 10.1.1.1 0*64kB 
Apr 20 16:20:06 10.1.1.1 0*128kB 
Apr 20 16:20:06 10.1.1.1 1*256kB 
Apr 20 16:20:06 10.1.1.1 1*512kB 
Apr 20 16:20:06 10.1.1.1 1*1024kB 
Apr 20 16:20:06 10.1.1.1 0*2048kB 
Apr 20 16:20:06 10.1.1.1 1*4096kB 
Apr 20 16:20:06 10.1.1.1 = 5920kB
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 HighMem: 
Apr 20 16:20:06 empty  
Apr 20 16:20:06 Swap cache: add 39530881, delete 39532596,  find  16672794 /18285464 , race 28+613
Apr 20 16:20:06 Free swap  = 0kB
Apr 20 16:20:06 Total swap = 7823612kB
Apr 20 16:20:06 Free swap:            0kB
Apr 20 16:20:06 2293760 pages of RAM
Apr 20 16:20:06 251202 reserved pages
Apr 20 16:20:06 39722 pages shared
Apr 20 16:20:06 10.1.1.1 [] pages swap cached
Apr 20 16:20:06 10.1.1.1 oom-killer: gfp_mask=0x280d2, order=0
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Call Trace: 
Apr 20 16:20:06 10.1.1.1  [<ffffffff802a66b4>] out_of_memory+0x33 /0x216
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020e020>] __alloc_pages+0x220 /0x2a9
Apr 20 16:20:06 10.1.1.1  [<ffffffff80208546>] __handle_mm_fault+0x1a3 /0x91a
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020a69c>] do_page_fault+0x39d /0x706
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020b009>] vfs_read+0x13c /0x171
Apr 20 16:20:06 10.1.1.1  [<ffffffff80258925>] error_exit+0x0 /0x84
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 10.1.1.1 Mem-info: 
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 DMA per-cpu: 
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 cpu 0 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 0 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 1 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 1 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 2 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 2 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 3 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 3 cold: high 0, batch 1 used:0
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 DMA32 per-cpu: 
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 cpu 0 hot: high 186, batch 31 used:35
Apr 20 16:20:06 cpu 0 cold: high 62, batch 15 used:19
Apr 20 16:20:06 cpu 1 hot: high 186, batch 31 used:17
Apr 20 16:20:06 cpu 1 cold: high 62, batch 15 used:55
Apr 20 16:20:06 cpu 2 hot: high 186, batch 31 used:30
Apr 20 16:20:06 cpu 2 cold: high 62, batch 15 used:48
Apr 20 16:20:06 cpu 3 hot: high 186, batch 31 used:12
Apr 20 16:20:06 cpu 3 cold: high 62, batch 15 used:56
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 Normal per-cpu: 
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 cpu 0 hot: high 186, batch 31 used:22
Apr 20 16:20:06 cpu 0 cold: high 62, batch 15 used:21
Apr 20 16:20:06 cpu 1 hot: high 186, batch 31 used:14
Apr 20 16:20:06 cpu 1 cold: high 62, batch 15 used:59
Apr 20 16:20:06 cpu 2 hot: high 186, batch 31 used:15
Apr 20 16:20:06 cpu 2 cold: high 62, batch 15 used:29
Apr 20 16:20:06 cpu 3 hot: high 186, batch 31 used:56
Apr 20 16:20:06 cpu 3 cold: high 62, batch 15 used:53
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 HighMem per-cpu: 
Apr 20 16:20:06 10.1.1.1  empty
Apr 20 16:20:06 Free pages:       42168kB (0kB HighMem)
Apr 20 16:20:06 10.1.1.1 Active: 794087 inactive:1196940 dirty:0 writeback:0 unstable:0  free :10542 slab:13489 mapped:53 pagetables:15831
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 DMA  free : 12548kB min:16kB low:20kB high:24kB active:0kB inactive:0kB present:12200kB pages_scanned:0 all_unreclaimable?  yes
Apr 20 16:20:06 10.1.1.1 lowmem_reserve[]: 
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  3246
Apr 20 16:20:06 10.1.1.1  8044
Apr 20 16:20:06 10.1.1.1  8044
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 DMA32  free : 23700kB min:4628kB low:5784kB high:6940kB active:3205620kB inactive:23368kB present:3324740kB pages_scanned:810574620 all_unreclaimable? no
Apr 20 16:20:06 10.1.1.1 lowmem_reserve[]: 
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  4797
Apr 20 16:20:06 10.1.1.1  4797
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 Normal  free : 5920kB min:6840kB low:8548kB high:10260kB active:5744kB inactive:4729248kB present:4912640kB pages_scanned:1232655726 all_unreclaimable? no
Apr 20 16:20:06 10.1.1.1 lowmem_reserve[]: 
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 HighMem  free : 0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Apr 20 16:20:06 10.1.1.1 lowmem_reserve[]: 
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  0
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 DMA: 
Apr 20 16:20:06 10.1.1.1 3*4kB 
Apr 20 16:20:06 10.1.1.1 5*8kB 
Apr 20 16:20:06 10.1.1.1 5*16kB 
Apr 20 16:20:06 10.1.1.1 4*32kB 
Apr 20 16:20:06 10.1.1.1 4*64kB 
Apr 20 16:20:06 10.1.1.1 2*128kB 
Apr 20 16:20:06 10.1.1.1 0*256kB 
Apr 20 16:20:06 10.1.1.1 1*512kB 
Apr 20 16:20:06 10.1.1.1 1*1024kB 
Apr 20 16:20:06 10.1.1.1 1*2048kB 
Apr 20 16:20:06 10.1.1.1 2*4096kB 
Apr 20 16:20:06 10.1.1.1 = 12548kB
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 DMA32: 
Apr 20 16:20:06 10.1.1.1 1*4kB 
Apr 20 16:20:06 10.1.1.1 0*8kB 
Apr 20 16:20:06 10.1.1.1 1*16kB 
Apr 20 16:20:06 10.1.1.1 0*32kB 
Apr 20 16:20:06 10.1.1.1 2*64kB 
Apr 20 16:20:06 10.1.1.1 0*128kB 
Apr 20 16:20:06 10.1.1.1 0*256kB 
Apr 20 16:20:06 10.1.1.1 0*512kB 
Apr 20 16:20:06 10.1.1.1 1*1024kB 
Apr 20 16:20:06 10.1.1.1 1*2048kB 
Apr 20 16:20:06 10.1.1.1 5*4096kB 
Apr 20 16:20:06 10.1.1.1 = 23700kB
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 Normal: 
Apr 20 16:20:06 10.1.1.1 0*4kB 
Apr 20 16:20:06 10.1.1.1 0*8kB 
Apr 20 16:20:06 10.1.1.1 0*16kB 
Apr 20 16:20:06 10.1.1.1 1*32kB 
Apr 20 16:20:06 10.1.1.1 0*64kB 
Apr 20 16:20:06 10.1.1.1 0*128kB 
Apr 20 16:20:06 10.1.1.1 1*256kB 
Apr 20 16:20:06 10.1.1.1 1*512kB 
Apr 20 16:20:06 10.1.1.1 1*1024kB 
Apr 20 16:20:06 10.1.1.1 0*2048kB 
Apr 20 16:20:06 10.1.1.1 1*4096kB 
Apr 20 16:20:06 10.1.1.1 = 5920kB
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 10.1.1.1 HighMem: 
Apr 20 16:20:06 empty  
Apr 20 16:20:06 Swap cache: add 39530881, delete 39532596,  find  16672794 /18285464 , race 28+613
Apr 20 16:20:06 Free swap  = 0kB
Apr 20 16:20:06 Total swap = 7823612kB
Apr 20 16:20:06 Free swap:            0kB
Apr 20 16:20:06 2293760 pages of RAM
Apr 20 16:20:06 251202 reserved pages
Apr 20 16:20:06 39699 pages shared
Apr 20 16:20:06 10.1.1.1 [] pages swap cached
Apr 20 16:20:06 10.1.1.1 oom-killer: gfp_mask=0x280d2, order=0
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 Call Trace: 
Apr 20 16:20:06 10.1.1.1  [<ffffffff802a66b4>] out_of_memory+0x33 /0x216
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020e020>] __alloc_pages+0x220 /0x2a9
Apr 20 16:20:06 10.1.1.1  [<ffffffff80208546>] __handle_mm_fault+0x1a3 /0x91a
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020a69c>] do_page_fault+0x39d /0x706
Apr 20 16:20:06 10.1.1.1  [<ffffffff8020b009>] vfs_read+0x13c /0x171
Apr 20 16:20:06 10.1.1.1  [<ffffffff80258925>] error_exit+0x0 /0x84
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 10.1.1.1 Mem-info: 
Apr 20 16:20:06 Node 0 
Apr 20 16:20:06 DMA per-cpu: 
Apr 20 16:20:06 10.1.1.1  
Apr 20 16:20:06 cpu 0 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 0 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 1 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 1 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 2 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 2 cold: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 3 hot: high 0, batch 1 used:0
Apr 20 16:20:06 cpu 3 cold: high 0, batch 1 used:0
==============================================================================
DELL R410的机器 查看日志发现是内存和swap(原来是8G)都用完宕机,之后找到相应项目沟通
1、修改相应程序
2、加大物理内存









本文转自 xdoujiang 51CTO博客,原文链接:http://blog.51cto.com/7938217/1650782,如需转载请自行联系原作者
目录
相关文章
|
2月前
|
数据挖掘 Linux
服务器数据恢复-重装系统导致XFS分区丢失的数据恢复案例
服务器数据恢复环境: MD1200磁盘柜中的磁盘通过RAID卡创建了一组RAID5阵列,分配了一个LUN。在Linux操作系统层面对该LUN进行了分区,划分sdc1和sdc2两个分区,通过LVM扩容的方式将sdc1分区加入到了root_lv中;sdc2分区格式化为XFS文件系统。 服务器故障: 服务器重装系统后,磁盘分区改变,sdc2分区丢失,无法访问。
服务器数据恢复-重装系统导致XFS分区丢失的数据恢复案例
|
3月前
|
存储 算法 Oracle
服务器数据恢复—EVA存储硬盘不稳定离线的数据恢复案例
服务器数据恢复环境: 某品牌EVA某型号存储,底层是RAID5阵列,划分了若干lun。 服务器故障&分析: 该存储设备中raid5阵列有两块硬盘掉线,存储中的lun丢失。 将故障服务器存储中的所有磁盘编号后取出,硬件工程师检测后发现掉线硬盘不存在物理故障,也没有发现坏道,都可以正常读取数据。
|
23天前
|
存储 数据挖掘 Windows
服务器数据恢复—异常断电导致raid信息丢失的数据恢复案例
由于机房多次断电导致一台服务器中raid阵列信息丢失。该阵列中存放的是文档,上层安装的是Windows server操作系统,没有配置ups。 因为服务器异常断电重启后,raid阵列可以正常使用,所以未引起管理员的注意。后续出现的多次异常断电导致raid报错,服务器无法找到存储设备,进入raid管理模块进行任何操作都会导致操作系统死机。管理员尝试多次重启服务器,故障依旧。
|
25天前
|
存储 运维 安全
服务器数据恢复—存储互斥不当导致VMFS卷损坏的数据恢复案例
某公司的信息管理平台,通过3台虚拟机共享了一台存储设备供企业内部使用,存储设备中存放了公司内部重要的数据文件。 由于业务增长的需要,管理员又在这个存储网络上连接了一台Windows server服务器,结果这台存储变得不可用了。 管理员对该存储进行故障排查时发现存储中虚拟磁盘丢失,分区表丢失。重启该存储设备后故障依旧。 由于存储中的数据十分重要,没有备份。管理员为了安全起见,联系北亚企安数据恢复中心寻求帮助。 经过硬件工程师的检测,没有发现存储存在硬件故障。存储中的硬盘经过硬件工程师的检测后也没有发现任何物理故障,都可以正常读取。基本上可以排除故障是由于硬件导致的。
|
28天前
|
数据挖掘
服务器数据恢复—服务器硬盘掉线,指示灯显示红色的数据恢复案例
一台服务器中有一组由多块硬盘组建的raid阵列,在运行过程中服务器突然崩溃,管理员检查服务器发现该服务器raid阵列中有两块硬盘的指示灯显示红色。于是,管理员重启服务器,服务器重启后,先离线的硬盘上线并开始自动同步数据,数据同步过程中管理员又将服务器强制关机。
服务器数据恢复—服务器硬盘掉线,指示灯显示红色的数据恢复案例
|
29天前
|
存储 数据挖掘
服务器数据恢复—raid5热备盘同步失败的数据恢复案例
一台存储上有一组由多块硬盘组建的raid5阵列,该raid5阵列中的一块硬盘掉线,热备盘自动上线同步数据的过程中,raid阵列中又有一块硬盘掉线,热备盘的数据同步被中断,raid5阵列失效,卷挂载不上,存储瘫痪。 这类raid故障比较常见,服务器raid中的硬盘大多数情况下都是一个批次的同品牌同型号的硬盘,一旦有硬盘出现故障掉线,那么其他硬盘也随时有出故障掉线的可能。
|
1月前
|
弹性计算
ECS服务保活和宕机启动
学习ECS服务保活、宕机启动的配置方法,并体验其实现效果。通过应用程序配置保活和宕机启动策略,可以确保关键服务在遇到各种问题时保持运行,从而为用户和企业提供稳定和可靠的服务。
|
1月前
|
存储 Oracle 关系型数据库
服务器数据恢复—北亚企安服务器数据恢复案例集锦
服务器数据恢复案例之服务器raid6中3个磁盘离线导致阵列崩溃的数据恢复案例 服务器数据恢复案例之服务器RAID5两个磁盘指示灯显示红色导致服务器崩溃的数据恢复案例 服务器数据恢复案例之服务器硬盘出现坏道/坏扇区离线导致服务器崩溃的数据恢复案例
|
1月前
|
存储 Ubuntu 网络安全
|
1月前
|
存储 算法 数据库
【服务器数据恢复】raid5多块硬盘离线导致昆腾存储崩溃的数据恢复案例
10个磁盘柜,每个磁盘柜配24块硬盘。9个磁盘柜用于存储数据,1个磁盘柜用于存储元数据。 元数据存储中24块硬盘,组建了9组RAID1阵列+1组RAID10阵列,4个全局热备硬盘。 数据存储中,组建了36组6硬RAID5,36组RAID5阵列划分为2个存储系统。其中1个存储系统中的一组RAID5中有2块硬盘先后出现故障离线,RAID5阵列不可用,存储系统崩溃。
【服务器数据恢复】raid5多块硬盘离线导致昆腾存储崩溃的数据恢复案例

热门文章

最新文章