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月前
|
存储 数据挖掘 Windows
服务器数据恢复—V7000存储raid5故障导致LUN无法访问的数据恢复案例
服务器数据恢复环境: 三台V7000存储,共有64块SAS硬盘(其中有三块热备盘,其中一块已启用)组建了数组raid5阵列。分配若干LUN,上层安装Windows server操作系统,数据分区格式化为NTFS文件系统。 服务器故障: V7000存储中有多块硬盘出现故障离线,阵列失效,LUN无法访问。需要恢复卷中所有数据(主要为dcm文件)。
|
1月前
|
存储 Oracle 关系型数据库
服务器数据恢复—EVA存储硬盘读写性能不稳定掉线的数据恢复案例
服务器存储数据恢复环境: 一台EVA某型号控制器+EVA扩展柜+FC磁盘。 服务器存储故障&检测: 磁盘故障导致该EVA存储中LUN不可用,导致上层应用无法正常使用。
96 47
|
8天前
|
存储 运维 数据挖掘
服务器数据恢复—EVA存储中多块硬盘离线导致存储崩溃的数据恢复案例
一台HP EVA存储中有23块硬盘,挂接到一台windows server操作系统的服务器。 EVA存储上有三个硬盘指示灯亮黄灯,此刻存储还能正常使用。管理员在更换硬盘的过程中,又出现一块硬盘对应的指示灯亮黄灯,存储崩溃,无法使用了。
|
1月前
|
数据挖掘 Linux 数据库
服务器数据恢复—reiserfs文件系统数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由4块SAS硬盘组建的RAID5阵列,上层安装linux操作系统统。分区结构:boot分区+LVM卷+swap分区(按照顺序),LVM卷中划分了一个reiserfs文件系统作为根分区。 服务器故障: 服务器操作系统在运行过程中由于未知原因崩溃,管理员重装操作系统后发现分区结构变为:boot分区+swap分区+LVM卷(按照顺序),LVM卷中文件系统位置有个空的reiserfs超级块。 用户方需要恢复reiserfs文件系统中所有数据,包含数据库、网站程序与网页、OA系统中所有办公文档。
服务器数据恢复—reiserfs文件系统数据恢复案例
|
21天前
|
存储 Oracle 关系型数据库
服务器数据恢复—DS5300存储raid5阵列数据恢复案例
服务器存储数据恢复环境: 某单位一台某品牌型号为DS5300的服务器存储,1个机头+4个扩展柜,底层是2组分别由数十块硬盘组建的RAID5阵列。存储系统上层一共分了11个卷。 服务器存储故障&分析: 存储设备上一组raid5阵列上的2块磁盘出现故障,对应的硬盘指示灯亮黄灯,阵列崩溃,存储不可用。该组故障阵列上层存放的是Oracle数据库文件。
|
27天前
|
存储 运维 数据挖掘
服务器数据恢复—华为OceanStor存储数据恢复案例
服务器存储数据恢复环境: 华为品牌型号为OceanStor S2600T的存储设备,存储上有一组由24块4T容量的机械硬盘组建的RAID5阵列,作为存储池使用。 图1 服务器存储故障&检测: 存储设备中raid5阵列上多块硬盘出现故障离线,raid5阵列失效,数据无法正常访问。 关机后将存储中所有硬盘标记&取出,硬件工程师对所有硬盘进行硬件故障检测。经过检测,没有发现存在物理故障的磁盘,都可以正常读取。
|
28天前
|
存储 Linux
服务器数据恢复——使用fsck后Ext4文件系统挂载不上的数据恢复案例
关于Ext4文件系统的几个概念: 块组:Ext4文件系统的全部空间被划分为若干个块组,每个块组结构基本上相同。 块组描述符表:每个块组都对应一个块组描述符,这些块组描述符统一放在文件系统的前部,称为块组描述符表。每个块组描述符大小为32字节,主要描述块位图、i-节点位图及i-节点表的地址等信息。 超级块(Superblock):用于存储文件系统的配置参数(块大小、总块数、i-节点数等)和动态信息(当前空闲块数和i-节点数)。Ext4文件系统的超级块始于1024字节处,即2号扇区。 i节点:描述文件的时间、大小、块指针等信息。
|
7天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
存储 数据挖掘
服务器数据恢复—EqualLogic存储raid5阵列多块硬盘掉线的数据恢复案例
服务器存储数据恢复环境: 一台EqualLogic存储中有一组由16块SAS硬盘组建的RAID5阵列。上层划分了4个卷,采用VMFS文件系统,存放虚拟机文件。 服务器存储故障: 存储RAID5阵列中磁盘出现故障,有2块硬盘对应的指示灯亮黄灯,存储不可用,且存储设备已经过保。
|
1月前
|
存储 运维 数据挖掘
服务器数据恢复—EVA存储删除VDISK的数据恢复案例
服务器存储数据恢复环境: 某单位有一台EVA某型号存储主机+2个扩展柜,共12个FATA磁盘+10个FC磁盘,LUN数量不确定,操作系统为WINDOWS SERVER。该存储用来存放单位的历史案例审理材料。 服务器存储故障&检测: 该EVA存储出现故障,无法正常使用。而且经过几家数据恢复服务商的操作,具体故障原因已经无法确定。