进程异常core文件分析

1. core文件相关配置

1.1 查看core文件是否开启

Core file size 为0 代表关闭core文件，unlimited 代表开启core文件。

开启core文件以后，代表进程异常以后，会生成core文件。

使用ulimit -a 查看core文件信息。

临时关闭core文件配置。

[root@localhost ~]# ulimit -c 0

以下是参数

永久生效

1.2 core文件的名称和路径配置

默认生成路径:输入可执行文件运行命令的同一路径下默认生成名称:默认命名为core,新的core文件会覆盖旧的core文件

设置pid作为文件扩展名:

Echo “1”>/proc/sys/kernel/core_uses_pid或者sysctl -w kernel.core_uses_pid=1

修改临时生效core文件路径

mkdir /corefile

chmod 777 /corefile

Echo “/corefile/%e.core.%p”>/proc/sys/kernel/core_pattern

Sysctl -w kernel.core_pattern=/corefile/core-%e-%p-%t

永久生效需要配置/etc/sysctl.conf文件

echo "kernel.core_pattern=/corefile/%e.core.%p" >> /etc/sysctl.conf

1.3 验证core文件配置是否生效

执行kill -11  进程号会生成core文件，例如:

Kill -11 4166

查看进程异常终止生成的core文件

1.4 查看已启动进程的limit配置查看

Cat /proc/4338/limits

1.5 core文件相关配置-注意事项

1.6 查看core文件工具

1.6.1 dmrdc工具

对于数据库产生的core文件，dm提供dmrdc工具进行 core文件的分析读取，此工具可以提取出core文件中的完整sql语句。

1.6.2 gdb工具

常用使用

[dmdba@localhost bin]$ gdb dmserver /corefile/core-dmserver-4166-1669464222

1.6.3 pstack/gstack工具

Pstack是一个shell脚本，用于打印正在运行的进程的栈跟踪信息，他实际上的gstack的一个链接，而gstack本身是基于gdb封装的一个shell脚本，此命令可显示每个进程的栈跟踪。Pstack必须相应进程的属主或者root运行，可使用pstack来确定进程挂起的位置，此命令允许使用唯一选项是要检查的进程的pid。

对于部分过程操作系统，pstack只能打印单线程的堆栈信息，需要脚本循环打印

[root@localhost /]# pstack 4338

1.7 core文件你分析-生成

进程异常有3种情况

1.7.1 服务主动core（dm_sys_halt）

数据库的断开处理，在检测到进程内部出现异常时自身选择自杀并给出提示信息，来防止更严重的错误产生，在数据库日志种会有dm_sys_halt的日志打印，内容附近会记录详细的问题原因，常见的异常情况比如，授权信息过期，文件完整性信息，内存是否污染信息，数据页校验信息等。

这种情况下导致进程中止，我们需要检查数据库运行日志，搜索halt相关内容，根据相关的信息进行对应的处理，一般情况下可以将数据库恢复至正常的运行状态，对于内存检验失败，数据文件检验失败相关信息需特别注意，可能是检测到有文件发生损坏导致，满足情况进程dbchk检查。

1.7.2 未知原因导致异常的core

数据库触发bug在没有任何提示的情况下突然终止运行，数据库日志不会打印具体错误信息，一般会在操作系统日志种出现segment fault类信息打印，我们可以在系统日志种搜索dm_或者dmserver找到对应线程异常信息

此类情况我们需要收集操作系统日志相关片段，数据库运行日志，异常core文件，core文件堆栈，d'mrdc相关信息进行分析，此类情况多为sql语句触发，此时我们应及时定位具体sql，然后及时和应用沟通或修改参数等方式，避免问题不断重复出现。

1.7.3 手动执行kill 删掉进程core

日常工作中我们会遇到数据库出现问题，不能很快定位问题，单因为现场环境我们需要第一时间恢复业务，此时为了后续我们进行问题排查，我们就需要手动把数据库进程coredump，记录下进程当前内存信息，kill -11 pid或者kill -sigsegv pid

1.8 dmrdc分析获取完整sql

如果数据库进程是core在dm_sql_thd线程，那么说明是执行sql语句触发的bug，此时我们可以通过dmrdc工具定位出完整的sql语句。

1. 使用dmrdc工具分析core文件获取所有的sql文件

[dmdba@localhost ~]$ dmrdc sfile=/corefile/core-dmserver-4166-1669464222 dfile=./core-dmserver-4166-1669464222_tmp

2. 通过gdb命令info thr获取thread 1对应线程号或者系统/var/log/kernl日志获取导致core的线程号

3. 查找出dmrdc解析文件中对应线程号的sql

1.8.1 获取core文件的完整堆栈

当遇到数据库异常中止问题，我们需要及时收集信息反馈给研发进行问题定位，其中包括core文件的完整堆栈

1. 使用gdb调式core文件

Gdb dmserver core-dmserver-xxxxxx

2. 设置堆栈输出文件名称

Set logging file gdb_1125.log

3. 开启记录功能

Set logging on

4. 打印所有线程堆栈

Thread apply all bt

5. 关闭记录

Set loggin off

1.8.2 获取一个正在执行会话的堆栈

日常运维工作中，我们经常会遇到一些其他情况，比如多次执行sql偶尔会卡顿的情况，此时我们可能希望获取到当前的这个会话线程的一些堆栈信息，从而进一步分析具体的问题原因。

1. 通过v$sessions 获取到会话的具体线程号

Select thrd_id,sql_text from v$sessions;

2. 通过pstack打印对应的线程的堆栈信息

注意:

获取线程信息有一定风险，可能会触发数据库进程宕机，进行操作前需要进行确认。

达梦社区网址:eco.dameng.com