苦恼的数据库主机重启问题排查与解决

　　情况是这样的，有一套测试数据库所在的主机在最近几个月，每个月都会重启一至两次，由于数据库配置了开机自启动，且每次重启时间都比较短暂，便没有得到重视。最近由于测试人员的反馈，每当主机重启后呢会导致大片的测试应用由于断连导致无法使用，每次都需要重启应用才会好。那么我们就需要介入认真排查一下问题所在了，恰巧最近一次的重启时间为

　　11 月 10 日 18:29 左右，需要针对此问题分析 os 重启原因。

　　测试数据库所在的主机每个月都会重启一至两次，主机重启时数据库 alert 没有任何日志，操作系统日志没有异常信息，监控平台也是到每次重启前就无法获取到数据了，由于操作系统层参数配置，每次宕机都会生成 core dump。

　　cat /etc/sysctl.conf | grep core

　　kernel.core_pattern = /home/backup/crash/core-%e-円%s-%t

　　AWR 报告分析

　　因为数据库因 os 重启而重启了，所以跨宕机时间点的 AWR 报告无法采集，只能采集宕机前的 AWR 报告，即 11 月 10 日

　　17:00—18：00，从这个时间段 AWR 报告来看，数据库负载不算太高，且数据库各指标也都比较正常，因为这个 AWR

　　报告距离宕机时间还有半个小时，所以也无法准确体现宕机时间点的数据库状态。ASH 报告分析

　　通过收集到的 ASH 信息，当时数据库基本上是忙于 CPU 的调度与等待，“CPU + Wait for CPU” 等待事件比较多，但想要查看进一步的信息就没有了。

　　数据库日志分析

　　宕机时间点附近 alert 日志、数据库监听日志均没有异常信息打印。OSW 日志分析

　　OSWatcher 使用简介

　　OSW 是用于采集 OS 性能指标的工具，调用 OS 的命令，对 OS 资源的占用可以忽略不计。

　　OSW 包含两个组件：

　　oswbb  : 一组 shell 脚本，采集 OS 的性能指标数据。

　　oswbba : java 工具，分析 oswbb 采集的数据，提供一些建议，根据采集的数据绘制 CPU，内存，网络，I/O 的曲线图。

　　因为在上一次宕机也就是 11 月 2 日之后我部署了 OSW 工具，现在就可以看看宕机前的几分钟 OSW 抓取到的数据，以此数据来分析宕机前 OS 状态。

　　从宕机前收集到的 OSW 数据来看，IO 和 CPU 的使用率是比较正常的，但 free memory 只有 300M 多了，初步判断可能和操作系统内存有关。收集特定时间段的 OSW 数据

　　查看 OSW 的数据存储位置

　　收集指定时间段的日志，例如：

　　使用 oswbba 分析 OSW

　　注意要打开图形化

　　分析 archive 目录下的所有 OSW 数据采集文件，并生成 HTML 报告。

　　指定时间段分析 archive 目录下的 OSW 数据采集文件，并生成 HTML 报告。

　　打开图形化界面然后执行 oswbba.jar 便会生成类似于下面的 gif 图形，通过此趋势图可以看到 18:28 分左右内存和 Swap 出现峰值，也说明当时内存使用过多了。

　　参考文档：

　　OSWatcher (Includes: [Video]) (文档 ID 301137.1)

　　OS Watcher User’s Guide (文档 ID 1531223.1)

　　OSWatcher Analyzer User Guide (文档 ID 461053.1)操作系统日志分析

　　宕机时间点附近 /var/log/messages 中也没有异常信息打印。

　　那么基于上面的这些信息基本上排查不到什么有用的信息了，唯一能有突破的就是前面说的每次重启都生成的 core 文件了。我们知道在 Linux

　　系统中，如果进程崩溃了，系统内核会捕获到进程崩溃信息，然后将进程的 coredump 信息写入到文件中，这个文件名默认是 core

　　。存储位置与对应的可执行程序在同一目录下，文件名是core，大家可以通过下面的命令看到 core 文件的存在位置，如下我的配置是在

　　/home/backup/crash/ 目录下。

　　cat /proc/sys/kernel/core_pattern

　　/home/backup/crash/core-%e-円%s-%t

　　core 文件需要 gdb 命令打开分析，这里就不班门弄斧了，专业的事交给专业的人去干，通过系统工程师的分析，OS 所在主机的安全狗

　　watchdog 进程夯 120 秒导致主机重启。这里就要说明下为何夯 120 秒主机就会重启，因为配置了操作系统参数

　　kernel.hung_task_panic = 1 导致主机重启了。

　　kernel.hung_task_panic

　　操作系统工程师配置了这个内核参数 kernel.hung_task_panic=1 ，官方意思是如果内核有进程处于 D 状态在 120s

　　内都没有被调度，则默认会触发 panic，说的通俗易懂点就是配置这个参数时当主机有进程夯 120

　　秒时就会触发主机重启机制。那么问题就很明白了，每次的重启都是由于有进程夯了 120 秒触发了这个参数的设置导致主机重启。如果要关闭 hung

　　task panic，则可以设置内核参数 kernel.hung_task_panic=0

　　进行关闭。所以这里呢我也就将这个参数注释掉，默认值就是 0。

　　系统工程师通过 crash 工具分析 core dump 可以看到宕机时的 os 内存使用已经达到了 98%，并且 swap 也已经使用了 68%。

　　由此基本上可以看到是由于内存耗尽导致重启了。然后进一步检查数据库内存参数配置，目前此虚拟机的物理内存为 32G，sga

　　16G，pga  4G ，没有配置内存大页，数据库参数 processes 设置为 2000，pga_aggregate_limit

　　没有值。那么在这种配置下数据库连接数比较多的情况下，每个数据库连接占用 3-5m 内存多达 1000 多个链接的情况下在出现几个排序的大

　　SQL，很容易把内存占完。

　　通过以上的分析，基本可以确定，数据库主机宕机的原因是内存不足导致，一来操作系统内存 32G 对数据库而言没有限制，二来数据库存在大量连接会话，大量低效 SQL 占用大量内存空间导致内存资源不足。

　　建议：

　　1、增加主机物理内存，从现在的 32G，增加至 64G；

　　2、调整 SGA 和 PGA 大小并设置 pga_aggregate_limit；

　　3、开启内存大页；

　　4、在操作系统层面对数据库内存使用进行限制；

　　5、取消内核参数 kernel.hung_task_panic

　　先调整数据库 SGA 和 PGA 大小。参数 PGA_AGGREGATE_TARGET 起到的是目标的作用，而非限制实际 PGA

　　大小，参数 PGA_AGGREGATE_LIMIT 是 12c 以后开始的新参数，可以对 PGA 的内存使用量作“硬性规定”。如果 PGA

　　超过了 PGA_AGGREGATE_LIMIT 值，那么 Oracle 内部按照以下顺序，中断或者终止使用了最多不可优化的 PGA 内存（the

　　most untunable PGA）的会话或进程：

　　CKPT 进程会检查（每三秒检查一次）并停掉使用了最多不可优化 PGA 内存的会话调用;

　　如果 PGA 内存使用量仍超过 PGA_AGGREGATE_LIMIT，则 CKPT 进程会终止使用了最多不可优化 PGA 内存的会话和进程.

　　在 Oracle 12.1 的版本中会选择以下三种情况中最大的值作为PGA_AGGREGATE_LIMIT 的值：

　　1）2 GB

　　2）PGA_AGGREGATE_TARGET 值的 2 倍

　　3）参数 PROCESSES 的值 * 3MB

　　另外需要注意的是：该参数不会超过物理内存大小减去总 SGA 大小的 120%。

　　在 18c 以后的版本中，PGA_AGGREGATE_LIMIT 的值计算方法大概是如下的公式：

　　PGA_AGGREGATE_LIMIT = (原始 PGA_AGGREGATE_LIMIT 值) + ((最大连接进程数) * 4M)

　　所以本次调整虚拟机内存为 64G 后，设置 SGA、PGA 参数如下：

　　然后需要开启内存大页

　　vm.min_free_kbytes 这个参数可以控制预留给虚拟机多少内存，设置的太小会出现死锁，设置的过大会出现 OOM。为了满足

　　PF_MEMALLOC，需要一些最小的内存分配;如果您将其设置为低于1024KB，系统将会变得微妙地破碎，并且在高负载下容易死锁，设置过高会使你的机器立即

　　OOM；通常经验值是设置物理内存的 2%-5% 以内，单位是 KB，通常情况下 32G 内存配置 2G，64G 内存配置 5G 即

　　5242880 ，128G 内存 10G 即可。

　　参考链接：https://www.kernel.org/doc/Documentation/sysctl/vm.txt

　　内存大页，大内存页，标准大页等均是同一个东西，之前写的《Linux 透明大页 THP 和标准大页 HP》一文有过详细介绍，这里就不再介绍了。

　　memlock 参数指定用户可以锁定其地址空间的内存量。在 /etc/security/limits.conf 文件中添加 memlock 的限制，一般情况下该值略微小于实际物理内存的大小（单位为 KB）,我的物理内存是 64GB，可以设置为如下：

　　通过以上设置后就可以关机修改内存至 64G 然后开机检查数据库状态了。

　　经过以上设置，观察了一个多月的时间没有出现过重启或者资源不足的情况，在此简单记录一下排查过程以及用到的知识点，希望以后遇到类似的问题可以参考参考，如果小伙伴们有不同意见或建议，欢迎一起交流。