DM 达梦数据库 Core Dump 文件说明 -- cnDBA.cn

1 Core dump 概述

1.1 Core dump 说明

A core dump is the recorded state of the working memory of a computer program at a specific time, generally when the program has terminated abnormally (crashed). In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information. The name comes from the once-standard memory technology core memory. Core dumps are often used to diagnose or debug errors in computer programs.

On many operating systems, a fatal error in a program automatically triggers a core dump, and by extension the phrase “to dump core” has come to mean, in many cases, any fatal error, regardless of whether a record of the program memory is created.

在一个程序崩溃时，它一般会在指定目录下生成一个 core 文件。 core 文件仅仅是一个内存映象 ( 同时加上调试信息 ) ，主要是用来调试程序的信息。

发生doredump一般都是在进程收到某个信号的时候，Linux上现在大概有60多个信号，可以使用 kill -l 命令全部列出来。

[dave@www.cndba.cn3 bin]# kill -l
 1) SIGHUP     2) SIGINT     3) SIGQUIT     4) SIGILL     5) SIGTRAP
 6) SIGABRT     7) SIGBUS     8) SIGFPE     9) SIGKILL    10) SIGUSR1
11) SIGSEGV    12) SIGUSR2    13) SIGPIPE    14) SIGALRM    15) SIGTERM
16) SIGSTKFLT    17) SIGCHLD    18) SIGCONT    19) SIGSTOP    20) SIGTSTP
21) SIGTTIN    22) SIGTTOU    23) SIGURG    24) SIGXCPU    25) SIGXFSZ
26) SIGVTALRM    27) SIGPROF    28) SIGWINCH    29) SIGIO    30) SIGPWR
31) SIGSYS    34) SIGRTMIN    35) SIGRTMIN+1    36) SIGRTMIN+2    37) SIGRTMIN+3
38) SIGRTMIN+4    39) SIGRTMIN+5    40) SIGRTMIN+6    41) SIGRTMIN+7    42) SIGRTMIN+8
43) SIGRTMIN+9    44) SIGRTMIN+10    45) SIGRTMIN+11    46) SIGRTMIN+12    47) SIGRTMIN+13
48) SIGRTMIN+14    49) SIGRTMIN+15    50) SIGRTMAX-14    51) SIGRTMAX-13    52) SIGRTMAX-12
53) SIGRTMAX-11    54) SIGRTMAX-10    55) SIGRTMAX-9    56) SIGRTMAX-8    57) SIGRTMAX-7
58) SIGRTMAX-6    59) SIGRTMAX-5    60) SIGRTMAX-4    61) SIGRTMAX-3    62) SIGRTMAX-2
63) SIGRTMAX-1    64) SIGRTMAX    
[dave@www.cndba.cn3 bin]#

针对特定的信号，应用程序可以写对应的信号处理函数。如果不指定，则采取默认的处理方式, 默认处理是coredump的信号如下：

3)SIGQUIT   4)SIGILL    6)SIGABRT   8)SIGFPE    11)SIGSEGV    7)SIGBUS    31)SIGSYS
5)SIGTRAP   24)SIGXCPU  25)SIGXFSZ  29)SIGIOT

1.2 启用和禁用core dump

查看状态, 0 说明是禁止生成 core 文件。

[dave@www.cndba.cn3 bin]# ulimit -c
0
[dave@www.cndba.cn3 bin]#

如果 ulimit -c 0 则也是禁止产生 core 文件，而 ulimit -c 1024 则限制产生的 core 文件的大小不能超过 1024kb:

[dave@www.cndba.cn3 bin]# ulimit -c 1024
[dave@www.cndba.cn3 bin]# ulimit -c
1024
[dave@www.cndba.cn3 bin]#

使用参数unlimited，取消该限制：

[dave@www.cndba.cn3 bin]# ulimit -c unlimited
[dave@www.cndba.cn3 bin]# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30676

1.3 设置 Core Dump 的核心转储文件目录和命名规则

[dave@www.cndba.cn3 bin]# cat /proc/sys/kernel/core_uses_pid
1
[dave@www.cndba.cn3 bin]#

/proc/sys/kernel/core_uses_pid 可以控制产生的 core 文件的文件名中是否添加 pid 作为扩展，如果添加则文件内容为 1 ，否则为 0。

[dave@www.cndba.cn3 bin]# cat /proc/sys/kernel/core_pattern
|/usr/libexec/abrt-hook-ccpp /var/spool/abrt %s %c %p %u %g %t %h %e 636f726500
[dave@www.cndba.cn3 bin]#

proc/sys/kernel/core_pattern 可以设置格式化的 core 文件保存位置或文件名，比如原来文件内容是 core-%e
可以这样修改 :

echo “/corefile/core-%e-%p-%t” > core_pattern

将会控制所产生的 core 文件会存放到 /corefile 目录下，产生的文件名为 core- 命令名 -pid- 时间戳
以下是参数列表 :

%p - insert pid into filename 添加 pid
%u - insert current uid into filename 添加当前 uid
%g - insert current gid into filename 添加当前 gid
%s - insert signal that caused the coredump into the filename 添加导致产生 core 的信号
%t - insert UNIX time that the coredump occurred into filename 添加 core 文件生成时的 unix 时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加命令名

2 达梦的Core Dump

在上节我们了解到了Linux的Core Dump，因为达梦数据库有不同的版本，在我的测试版本中，系统产生了大量的Core Dump 文件：


[dave@www.cndba.cn1 bin]$ pwd
/dm/dmdbms/bin
[dave@www.cndba.cn1 bin]$ ll -lht core.*
-rw------- 1 dmdba dinstall 120M Mar 14  2029 core.27036
-rw------- 1 dmdba dinstall 656M Mar 12  2029 core.27456
-rw------- 1 dmdba dinstall 656M Mar 12  2029 core.27318
-rw------- 1 dmdba dinstall 656M Mar 12  2029 core.27218
-rw------- 1 dmdba dinstall 657M Mar 12  2029 core.27114
-rw------- 1 dmdba dinstall 124M Mar  7  2029 core.6386
-rw------- 1 dmdba dinstall 801M Mar  6  2029 core.13163
-rw------- 1 dmdba dinstall 801M Mar  6  2029 core.13031
-rw------- 1 dmdba dinstall 811M Mar  6  2029 core.12904
-rw------- 1 dmdba dinstall 846M Mar  6  2029 core.12558
-rw------- 1 dmdba dinstall 806M Mar  6  2029 core.12437
-rw------- 1 dmdba dinstall 808M Mar  6  2029 core.12278
-rw------- 1 dmdba dinstall 839M Mar  6  2029 core.12130
-rw------- 1 dmdba dinstall 804M Mar  6  2029 core.11984
-rw------- 1 dmdba dinstall 804M Mar  6  2029 core.11856
-rw------- 1 dmdba dinstall 843M Mar  6  2029 core.11736
-rw------- 1 dmdba dinstall 830M Mar  6  2029 core.11602
-rw------- 1 dmdba dinstall 804M Mar  6  2029 core.11475
-rw------- 1 dmdba dinstall 823M Mar  6  2029 core.11330
-rw------- 1 dmdba dinstall 804M Mar  6  2029 core.10748
-rw------- 1 dmdba dinstall 822M Mar  6  2029 core.10623
-rw------- 1 dmdba dinstall 828M Mar  6  2029 core.10503
-rw------- 1 dmdba dinstall 829M Mar  6  2029 core.10365
-rw------- 1 dmdba dinstall 805M Mar  6  2029 core.10236
-rw------- 1 dmdba dinstall 826M Mar  6  2029 core.10064
-rw------- 1 dmdba dinstall 801M Mar  6  2029 core.9895
-rw------- 1 dmdba dinstall 823M Mar  6  2029 core.9756
-rw------- 1 dmdba dinstall 807M Mar  6  2029 core.9629
-rw------- 1 dmdba dinstall 878M Mar  6  2029 core.8906
[dave@www.cndba.cn1 bin]$

起初发现这个问题是因为操作系统磁盘空间满了，导致数据库无法启动，进一步发现在DM_HOME/bin 目录下生成了大量的Core 文件。

但注意这里，我们的系统并没有启动core dump：


[dave@www.cndba.cn1 bin]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30676
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[dave@www.cndba.cn1 bin]$

这里使用的操作系统是中标麒麟 6.0. 据说这个版本有一点问题：


[dave@www.cndba.cn1 bin]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.0 (Santiago)
[dave@www.cndba.cn1 bin]$ cat /etc/issue
NeoKylin Linux General Server release 6.0  (Dhaulagiri) 
Kernel /r on an /m

[dave@www.cndba.cn1 bin]$

DM数据库版本是7.6：


[dave@www.cndba.cn1 bin]$ disql SYSDBA/SYSDBA

Server[LOCALHOST:5236]:mode is primary, state is open
login used time: 21.176(ms)
disql V7.6.0.95-Build(2018.09.13-97108)ENT 
Connected to: DM 7.1.6.95
SQL> select * from v$version;

LINEID     BANNER                                                       
---------- -------------------------------------------------------------
1          DM Database Server x64 V7.6.0.95-Build(2018.09.13-97108)ENT  
2          DB Version: 0x7000a

used time: 4.001(ms). Execute id is 18.
SQL>

Core dump 主要是帮助分析问题。我们这里可以删除所有的core dump 文件，然后重启DM 数据库，就恢复了正常。

3 分析DM 的Core Dump

DM 生成的core dump 文件我们可以使用gdb 命令进行分析，gdb的概述如下：

Linux 程序调式命令 GDB 概述
https://www.cndba.cn/dave/article/3731

Gdb 的命令格式是：

gdb 程序名 core 文件

DM 有关的程序命令如下：


[dave@www.cndba.cn1 bin]$ which dmserver 
/dm/dmdbms/bin/dmserver
[dave@www.cndba.cn1 bin]$ which dma
dmamon      dmamon_ctl  dmap        dmasmcmd    dmasmsvr    dmasmtool   
[dave@www.cndba.cn1 bin]$ which dmap
/dm/dmdbms/bin/dmap
[dave@www.cndba.cn1 bin]$

查看core dump：


[dave@www.cndba.cn1 bin]$ gdb dmserver core.9895
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-neokylin-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /dm/dmdbms/bin/dmserver...(no debugging symbols found)...done.
[New Thread 9963]
[New Thread 9907]
……
[New Thread 9905]

warning: Ignoring non-absolute filename: <./libdmfldr_comm.so>
Missing separate debuginfo for ./libdmfldr_comm.so
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/3d/fe1fd00908d058b2a38c2c47ed6755f3f1a082

……
warning: Ignoring non-absolute filename: <./libz.so>
Missing separate debuginfo for ./libz.so
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/18/d361994f2e6160b50d8e1a91b7318d2b90bd0c

warning: Ignoring non-absolute filename: <./libsnappy.so>
Missing separate debuginfo for ./libsnappy.so
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ba/658beac5e7f7765b75feaad63e93d787923232
Missing separate debuginfo for 
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/c9/f30327565da1c96e9866791213a896db4937a8
Reading symbols from /lib64/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/librt.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
……
Core was generated by `/dm/dmdbms/bin/dmserver /dm/dmdbms/data/HeFei/dm.ini -noconsole'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000049f2d0 in mem_heap_alloc_low ()
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-8.el6.x86_64 glibc-2.12-1.25.el6.ns6.01.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64 libcom_err-1.41.12-7.el6.x86_64 libcurl-7.19.7-26.el6.2.x86_64 libgcc-4.4.5-6.el6.ns6.01.x86_64 libidn-1.18-2.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 libssh2-1.2.2-7.el6.x86_64 libstdc++-4.4.5-6.el6.ns6.01.x86_64 nspr-4.8.7-1.el6.x86_64 nss-3.12.9-9.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64 nss-util-3.12.9-1.el6.x86_64 openldap-2.4.23-15.el6.x86_64 openssl-1.0.0-10.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0  0x000000000049f2d0 in mem_heap_alloc_low ()
#1  0x0000000000a8d85e in pts_cuser_stmt_with_org_sql ()
#2  0x0000000000a8dfe4 in pts_rewrite_sql_for_pwd_info ()
#3  0x0000000000b9208f in nexe_gen_scp_sql_for_stmt ()
#4  0x00000000006bd9f7 in sess4_stmt_gen_scp_sql ()
#5  0x0000000000dd645f in rep_process_prepare ()
#6  0x0000000000dd69a3 in rep_process_prep_and_exec ()
#7  0x0000000000dd6b02 in rep_process_common ()
#8  0x0000000000dd8231 in rep_redo_ddl ()
#9  0x0000000000dd8ceb in rep_redo_log ()
#10 0x0000000000dda2e8 in rep_worker_thread ()
#11 0x00000037668077e1 in start_thread () from /lib64/libpthread.so.0
#12 0x00000037664e573d in clone () from /lib64/libc.so.6
(gdb) l
1    xercesc/util/Base64.cpp: No such file or directory.
    in xercesc/util/Base64.cpp

Gdb的调试命令参考之前的gdb 概述。当然这些信息是给原厂分析问题用的。从运维角度来看意义不大。我这里的遇到的问题很可能是操作系统和达梦数据库之间的兼容性导致的。

因为之前在群里讨论中标麒麟 OS的问题时，有人提过这个系统低版本有问题。我测试的恰好是中标麒麟的6.0版本。虽然系统在不断的生成core dump，但达梦数据库的使用是正常的。

但是这里有2点值得关注：

1.在系统没有启动core dump的情况下，生成了达梦的core dump。
2.达梦的core dump 文件具大，单个文件就达到了800M。如果不关注磁盘空间，很容易把磁盘空间撑满。

所以在选择操作系统和达梦数据库时，还是要多关注他们之间的兼容性。

签到成功

CNDBA社区