进程异常core文件分析

1.core文件相关配置

1.1查看core文件是否开启

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

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

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

临时关闭core文件配置。

[root@localhost ~]# ulimit -c 0

以下是参数

进程异常core文件分析

永久生效

进程异常core文件分析

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

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

设置pid作为文件扩展名:

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

进程异常core文件分析

修改临时生效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

进程异常core文件分析

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

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

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

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

Kill -11 4166

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

进程异常core文件分析

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

Cat /proc/4338/limits

进程异常core文件分析

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

进程异常core文件分析

1.6查看core文件工具

1.6.1dmrdc工具

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

1.6.2gdb工具

进程异常core文件分析

常用使用

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

进程异常core文件分析

1.6.3pstack/gstack工具

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

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

[root@localhost /]# pstack 4338

进程异常core文件分析

1.7core文件你分析-生成

进程异常有3种情况

1.7.1服务主动core(dm_sys_halt)

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

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

1.7.2未知原因导致异常的core

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

进程异常core文件分析

进程异常core文件分析

此类情况我们需要收集操作系统日志相关片段,数据库运行日志,异常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的线程号

进程异常core文件分析

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

进程异常core文件分析

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