摘 要：Linux操作系统相较于windows操作系统是较为稳定的，但是在实际的应用环境中，由于各种各样的原因也会造成系统死机等严重故障。本文主要从linux系统内存管理机制，分析了由于内存管理机制问题所可能引起的系统死机原因。讲解了当系统出现死机现象时，如何通过设置相应的Coredump、Diskdump、Netdump来获取记录信息。另外，从软件方面和硬件方面分别分析了在实际应用中可能引起系统死机的各种原因。

　　关键字：LINUX，系统崩溃，内核

　　一、内存管理

　　管理机制

　　常常有用户提起，系统大量内存被占用，空闲内存所剩不多，认为系统存在内存泄漏，其实是对 Linux 系统的内存管理机制的特点不理解。首先最重要的一点，Linux内存管理的基本原则是没有资源应该被浪费。因为核心会使用尽可能多的内存，来缓存来自本地和远程的文件系统的信息，以提升系统效率。系统做读写操作的时候，会将与当前运行的进程相关的数据尽量存储在内存里。系统报告的缓存是缓冲和页缓存两者之和。缓存并不是在进程结束的时候被回收（你可能很快会启动另外一个进程，需要同样的数据），而是随需回收。比如，当你启动一个需要大量内存的进程时，Linux核心会从内存中回收缓存，将得到的内存分配给新的进程。

　　下面是一个例子（单位是MB）：

　　# free -m

　　total       used       free     shared    buffers     cached

　　Mem:       1000        900        100         0      350        350

　　-/+ buffers/cache:          200        800

　　在这里例子中，应用程序只使用了200MB内存，还有800MB空闲内存可以使用。

　　需要注意的条目：

　　物理已用内存 = 实际已用内存 + 缓冲 + 缓存

　　物理空闲内存 = 总物理内存 - 实际已用内存 - 缓冲 - 缓存

　　应用程序可用空闲内存 = 总物理内存 - 实际已用内存

　　应用程序已用内存 = 实际已用内存 - 缓冲 - 缓存

　　1）大内存支持

　　x86平台下， 红旗DC4.1和5.0所带的SMP 和hugemem核心都打开了PAE支持，也就是说都可以支持4G以上的物理内存。引入hugemem核心的目的并不是为了支持超过4G物理内存（SMP核心就可以支持了），而是为了更稳定地支持大内存x86系统（所谓大内存可以简单理解为超过12G内存的系统）。SMP和hugemem核心的唯一区别是hugemem核心中打入了4G/4G补丁，使用4G/4G补丁可以将直接映射的内核数据代码地址空间从1G扩大到4G，将进程的虚拟地址空间也由 3G扩大到4G。当物理内存过多时，管理这些物理内存的工作本身会占用不少宝贵的内核地址空间（所谓低端内存），此时虽然总的物理内存还有不少空闲，由于低端内存耗尽，也可能会导致内存紧张，触发OOM （Out of memory） killer，导致应用终止甚至核心崩溃。如果超过12G物理内存，一般建议使用hugemem内核。需要指出的是，如果需要大内存，最好的解决方法是用64位系统，而不是使用hugemem。

　　二、崩溃处理

　　通常在出现系统崩溃后，用户会担心再次出现故障，但是发现系统各日志中并没有记录到任何死机前后的信息，无法分析故障原因，认为已经无药可救。但是，实际上，Linux 有多种机制来保证发生系统崩溃后，可以获取有价值的信息用以分析问题。确定是硬件故障，还是应用程序bug 导致的。

　　Linux 中，有如下几种方法来获取各种崩溃时产生的信息。

　　1）Core dump

　　Core dump 通常用来调试应用程序错误，当某些应用程序运行出现异常崩溃时，可以开启系统的 core dump 功能，来得到一个程序崩溃时的内存信息，用来分析崩溃原因：

　　在/etc/profile里加上（或者修改）一条：

　　ulimit -c 0

　　运行命令：sysctl -w "kernel.core_name_format=/coredump/%n.core"

　　该命令意思是指core文件放在/coredump目录下，文件名是进程名+.core

　　2）Diskdump

　　diskdump工具提供了在单机上创建和采集vmcore（kernel dump）的能力，而无须使用网络。当内核本身出现崩溃的时候，当前的内存和CPU状态以及相关的信息都会被保存到一个支持diskdump的磁盘上的保留分区上。 在下一次重新启动的时候，当系统重新启动，diskdump的初始化脚本会从保留分区中读取保存的信息并创建一个vcore文件，然后这个文件被再次存放到/var/crash/目录下，文件名为127.0.0.1-<date>

　　如下是一个配置 HP SCSI 设备上启用 diskdump 的过程，如果不是 HP SCSI 设备（即设备名为 /dev/sdX的形式），则无须执行第三、四两个步骤。但需要在第一步前先执行命令： modprobe diskdump

　　第一步：编辑 /etc/sysconfig/diskdump文件，将一个空白分区的设备名填入后保存退出，例如：

　　DEVICE=/dev/cciss/c0d0p2

　　第二步：初使化 dump 设备

　　#service diskdump initialformat

　　警告：该分区的所以数据会丢失。

　　第三步：使用 cciss_dump 模块替换当前的 cciss 模块：

　　在 /etc/modprobe.conf 找到如下行：

　　alias scsi_hostadapter cciss

　　修改为：

　　alias scsi_hostadapter cciss_dump

　　再增加一行：

　　options cciss_dump dump_drive=1

　　注：假设diskdump文件中配置的为 /dev/cciss/c0d[#a]p[#b], 请设置为： options cciss_dump dump_drive=[#a]

　　第四步：重建 initrd 文件：

　　#mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.old

　　#mkinitrd /boot/initrd-`uname -r`.img `uname -r`

　　第五步：设置 diskdump 服务能够开机自启动：

　　# chkconfig diskdump on

　　3）Netdump

　　如果使用红旗DC4.0 或 3.0 版本系统，是不能支持 diskdump 的，可以利用netdump 来达到输出vmcore 的目的。但是Netdump要求至少有一个服务器以及任意数目的客户端。服务器用来接收客户端死机时的信息，客户端是经常死机的机器。

　　服务器配置：

　　1.检验netdump服务器是否安装完毕：

　　rpm -q netdump-server

　　如果未安装，请在光盘 RedFlag/RPMS/ 目录中找到 netdump-server 打头的软件

　　包，执行命令：

　　rpm -ivh  netdump-server-x.x.x.rpm （x为版本号）

　　进行安装。

　　2.服务器包安装后，用命令：

　　passwd netdump

　　更改用户的密码。

　　3.打开服务：

　　chkconfig netdump-server on

　　4.运行服务器：

　　service netdump-server start

　　客户端配置：

　　1.校验客户端是否已安装

　　rpm -q netdump

　　如果未安装，在光盘 RedFlag/RPMS/ 目录中找到 netdum 打头的软件包，执行命令：

　　rpm -ivh  netdump-x.x.x.rpm （x为版本号）

　　安装。

　　2.编辑文件/etc/sysconfig/netdump， 添加如下行：

　　NETDUMPADDR=192.168.0.5

　　192.168.0.5指 netdump 服务器地址。

　　3.运行下面的命令，出现提示符时输入密码：

　　service netdump propagate

　　4.打开客户端：

　　chkconfig netdump on

　　5.运行客户端：

　　service netdump start

　　任何客户端死机时，信息将通过网络送至netdump服务器并储存在其/var/crash目

　　录中。由netdump产生的转出文件名称默认为 vmcore。

　　三、故障分析

　　虽然我们可以通过上述的几种方法来获取应用程序或操作系统崩溃时的各种信息，但是分析这些问题有一定难度，普通用户很难从 vmcore 文件中分析出故障原因。

　　但是可以在发现系统出现崩溃问题，需要分析原因时，可以利有上述的方法，获取vmcore，然后联系专业技术支持人员分析。

　　四、常见问题

　　1）软件相关

　　i.系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，此类问题多数与应用程序Bug有关，不一定在所有相同配置系统中都会产生，但是一旦触发该Bug，就有可能发生崩溃。

　　ii.系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，也有一些情况是新增的应用需要做一定的操作系统配置，没有设置的话，也有可能出现资源利用问题，导致崩溃发生。

　　iii.系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，也有一些情况是应用的版本与操作系统版本不匹配，应用软件所需的系统库文件版本不对应，容易引发应用程序崩溃。

　　iv.系统平时运行正常，近期没有任何新增应用，也没有更改系统配置，却接连发生多次崩溃现象。此类问题多数是压力增大，超出了硬件所能承受的负载，耗尽资源，发生崩溃。

　　v.系统平时运行正常，近期无新增应用，系统负载也不高，却发生崩溃现象。不排除操作系统本身的问题，有可能某种操作诱发了一个系统Bug，发生崩溃。

　　2）硬件相关

　　i.新增内存后，系统经常发生崩溃现象，此类问题有可能是32位机器配置了超过12GB的内存，但没有使用 hugemem 核心导致，具体原因可参见第一节中的说明。

　　ii.机器使用期限较长，某个硬件发生故障，也会导致系统崩溃的发生。

　　iii.新配置的机器经常发生崩溃现象，有可能硬件较新，而驱动程序版本较低，一般可通过升级驱动解决，驱动一般集成在内核当中，常见的办法是升级内核版本。