首页 » 其它国产库 » Gbase 8s 生成的 af.xxx shmem.xxx文件是什么?

Gbase 8s 生成的 af.xxx shmem.xxx文件是什么?

今天有客户在南大通用数据库Gbase 8S生产环境发现/tmp目录下产生了较大的文件,属主是gbase产生,文件名如af.xxxx.rawstk和shmem.xxxxx.0, 这是什么呢?

从DB 的日志 online.log中会记录显示该文件 ,如
xxx will not be suspended because it is a daemon.see alse: $GBASEDBTDIR/tmp/af.xxx, shmem.xxx.0
straring crash time check of: 1, memory block headers 2,stacks

该日志通常用于分析system crash使用,类似其它数据库直接生成的coredump。online.log日志中有记录什么时间哪个进程遇到了错误,产生的日志文件在哪里。  有配置文件onconfig参数DUMPDIR和DUMPSHMEM控制, 有时可能会产生多个af文件,建议先关注第一个。

 

分析思路
1,检查节点状态

onstat -

onstat -g sql

2,检查配置参数

onstat -c |grep DUMPSHMEM

DUMPSHMEM 控制共享内存dumps开关,1表示会生成dump ;0禁止;2排除buffer pool大小,生成更小的文件。生产库一般建议配置为0, 如果启用,需要当前产生的dump文件目录和文件系统可用大小,当心文件系统耗尽, SHMTOTOL配置后会被限制。

buffer大小

onstat -c |grep BUFFERPOOL

会有2k,16k大小,2k用于系统使用,关注16k就可以,size*buffers 就是bufferpool大小,会影响dumpshmem文件大小。

动态修改方法

onmode -wf DUMPSHMEM=0

3,故障配置

onstat -g ras

变量 值 作用
AFMESSAGE 0x00000001 Display message in log message file
AFCORE 0x00000002 Dump core file
AFGCORE 0x00000004 Dump gcore file
AFDUMPSHMEM 0x00000008 Dump shared memory
AFHANGSERVER 0x00000010 Hang the server
AFHANGTHREAD 0x00000020 Hang the current thread
AFCHECKHANG 0x00000040 Hang the cur thread, or the server
AFCHECKCRASH 0x00000080 Hang the cur thread, or crash server
AFCHECKRELEASE 0x00000100 Hang the cur thread, or do nothing
AFCRASHSERVER 0x00000200 Crash the server
AFSERVERSTACK 0x00000400 Generate a stack trace from oninit
AFNOEVIDENCE 0x00000800 Do NOT call evidence.sh
AF_FAST_T_HANG 0x00002000 Specifically when hanging a thread

3, 分析af.xxxxx.rawstk文件
system crash, fail会生成af.xxx文件,文件中包含stack堆栈调用。

4, 分析shmem.xxx.0文件
Shared memory dumps记录了引擎失败的原因,是AF文件的补充信息,用于后台二线分析故障根因。

onstat <infile> {options}

onstat shemem.xxxxxx.0 -l

紧急处理
生成的af.xxx和shmem.xxx文件备份用于分析后可以直接rm删除。

打赏

,

目前这篇文章还没有评论(Rss)

我要评论