1 背景描述

数据库在使用的过程中，在某段时间内发生宕机现象。之后虽然恢复正常，但是想要找到宕机背后的原因，以防止相似的情况再次出现。
以下是本次宕机问题的定位过程，解决方法，以及经验总结。

2 问题定位

2.1 查看日志

在log文件夹下查看当月的日志文件。
发现其他时间段无明显异常，而宕机时间段日志缺失。

2.2 查看缺失时间段的系统日志

cat /var/log/messages-日期

找到以下关键信息：

2.3 结论

OOM，导致oom killer杀死dmserver进程

注：oom killer是LINUX 为了确保系统的内存资源不耗尽而设置的一个守护进程，当系统内存不足时，选择oomscore分数最高，并且占用内存资源较多的进程，主动杀掉该进程，确保操作系统不会彻底死掉。

3 解决方法

3.1 跳过oom killer

找到dmserver进程，改写oom_score_adj值，使该进程跳过oom killer

ps -ef | grep dmserver        #查看DM服务，找到dmserver进程
cd /proc/dmserver进程
echo -1000>oom_score_adj      #改写oom_score_adj值
cat oom_score_adj             #检查查看oom_score_adj值
cat oom_score                 #查看oom_score值

原理：当系统内存不足时，oom killer选择oom_score最高最占内存的进程杀掉来确保整个系统的稳定，那么只要降低dmserver进程的oom_score值，oom killer就会跳过dmserver进程。

3.2 数据库参数优化

进一步对数据库进行优化，从数据库层面降低数据库进程对内存资源占用过大的风险。

3.2.1资源规划

确认服务器中除开其他业务，数据库一般可使用的内存资源。

3.2.2 参数调整

确认好数据库一般可使用的资源后，根据可使用内存资源对数据库进行参数调整。
一般可对以下几个参数进行调整
BUFFER。内存足够的情况下，可根据数据文件的大小调整，内存不充足的情况下，可调整为可用物理内存的 60%~80%
BUFFER_POOLS。高并发 OLTP 场景下，可根据客户端的并发连接数或者中间件连接池的大小进行调整
MAX_BUFFER。系统最大缓冲区大小，以兆为单位。通常设置为与 BUFFER 相同
RECYCLE。当排序缓冲区及哈希缓冲区不足的情况下，系统会优先使用 RECYCLE 缓冲区，RECYCLE 缓冲区不够，再刷临时表空间。在 OLAP 场景下，如果存在大表之间的关联查询，可以将值调大，尽可能不要使用临时表空间
其他。还有相关资源规划的参数，因为不产生直接影响，所以不一 一表述，可根据实际情况进行调整。

4 总结

在发生宕机问题后，可通过查看数据库日志和系统日志的方式定位具体宕机原因。
OOM宕机的根本原因是，oom killer为保护操作系统不会彻底挂掉，会选择oomscore分数最高并且最占内存资源的进程杀掉。
数据库参数调整需要根据实际服务器使用情况进行。