[原创]core dump现象实例分析_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
3
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 5508 | 回复: 2   主题: [原创]core dump现象实例分析        下一篇 
yang.liu
注册用户
等级:少校
经验:1182
发帖:77
精华:1
注册:2014-1-3
状态:离线
发送短消息息给yang.liu 加好友    发送短消息息给yang.liu 发消息
发表于: IP:您无权察看 2014-4-11 15:53:13 | [全部帖] [楼主帖] 楼主

1 概述

XX局方邀请,鉴于局方有系统运行缓慢,以及应用有core dump现象,对局方tuxedo系统检查,排查问题,给出建议。

2问题描述

1)应用运行缓慢

据局方相关人员反映,应用系统最近一段时间有运行放缓的现象。

2)Core dump

局方某个应用有server 异常生成了core dump文件。

3)日志报错CMDTUX_CAT:1667

查看tuxedo日志文件,发现有CMDTUX_CAT:1667: WARN: Server(23144) processing terminated after SVCTIMEOUT异常。

4)日志报错WSNAT_CAT:128

查看日志有WSNAT_CAT:1283: ERROR: Network error (2) servicing network event异常。

3系统环境


操作系统版本

HP-UX 11.00

Tuxedo版本

Tuxedo 6.5

4详细分析 

1)应用运行缓慢

5号上午会议已讨论相关问题,结合应用方,数据库方的讨论,优先考虑应用数据库操作相关的逻辑。

2)Core dump

分析core文件,找出dump的具体点:

0xc016f754 in memset+0x5c () from /usr/lib/libc.2#1  0x46df0f8 in pri_field_set+0x104 ()#2  0x46de574 in pub_glob_set+0x36c ()#3  0x3514d34 in pub_deprptmain_setarr+0xbc4 ()#4  0x454c20 in pub_blprptmain_query+0x1b58 ()#5  0xd3e10 in ipub_blprptmain_query+0x750 ()#6  0x46e1abc in execservices+0x188 ()#7  0xb164 in blprpt+0xa0 ()#8  0xc467d478 in _tmsvcdsp+0x624 () from /home/tuxedo/tuxedo65/lib/libtux.sl#9  0xc4692da4 in _tmrunserver+0x260 () from /home/tuxedo/tuxedo65/lib/libtux.sl#10 0xc467ca04 in _tmstartserver+0x9c () from /home/tuxedo/tuxedo65/lib/libtux.sl#11 0xb094 in main+0x34 ()


与应用相关代码用红色标出。

3)日志报错CMDTUX_CAT:1667

CMDTUX_CAT:1667异常是属于当服务运行时间超出在Tuxedo配置文件中*service段设置的SVCTIMEOUT属性值时,tuxedo将自动kill掉该服务,局方应用启用了自动重启,所以该服务将自动杀掉然后自动启动,这个是tuxedo High available的一个表现,但是,局方日志中发现有大量的该日志,而且涉及的服务不是个别的,这个就比较不正常。

4)日志报错WSNAT_CAT:128

这个异常导致的原因有:

1.分配内存失败

2.函数调用gp_nwaccept()失败,该函数是接收新的请求,这个可能的是由于文件描述符限制造成的

3.ping WS/JSL port也可看到这些信息

5总结与建议

1)应用运行缓慢

鉴于数据库方提出数据库有性能提高的空间,如会议中有提到索引的建立。因为和应用方相关人员探讨,发现报CMDTUX_CAT:1667异常的相关服务中绝大部分是与数据库操作有关,具体请结合建议第三点中提到的方法,可能会达到更好的调优效果。

2)Core dump

就应用生成core文件,这个问题请应用方查相关代码,在上面core分析数据中用红色标记的,找出错误,最好尽快解决,生成core文件本身就表示问题属于比较严重,再加之生成core文件会占用大量IO等系统资源,这样对系统的稳定会有影响。

3)应用报错CMDTUX_CAT:1667

关于CMDTUX_CAT:1667异常,观察tuxedo配置文件,每个特定的service都已经配置相关的SVCTIMEOUT。而鉴于涉及的超时服务较集中,建议应用方对应用进行跟踪调试:

1. 测试应用到底慢在哪里,是网络,tuxedo,应用逻辑,还是数据库。可以使用打时间戳的方法。

2.测试服务具体响应时间,如果确实一个数据库操作时间比较长,设置的时间不够,建议调高SVCTIMEOUT参数的值,因为重启一个服务是比较耗资源的,设置一个最佳值也可以达到调优的效果。

4)日志报错WSNAT_CAT:128

该错误是由于系统限制造成的,包括硬件限制以及操作系统限制:

1.内存不足(用于创建新连接的所需的内存)

2.文件描述符不足

3.WSL/JSL响应缓慢(一个进程高CPU利用率),导致远端连接超时

4.网络问题

查看tuxedo应用服务器内存资源,发现在下午5点钟时内存使用情况仍达到90%,虚拟内存超过90%,建议加大内存。文件描述符方面,已观察系统配置,已经够用。由于是生产系统,无法跟踪WSL/JSL是否响应缓慢以及网络问题。




赞(0)    操作        顶端 
koei
版主
等级:上校
经验:3305
发帖:7
精华:0
注册:2011-7-21
状态:离线
发送短消息息给koei 加好友    发送短消息息给koei 发消息
发表于: IP:您无权察看 2014-4-16 8:24:53 | [全部帖] [楼主帖] 2  楼

能确保每次都能生成Core文件供你分析?

如何设置跟core dump有关的操作系统内核参数呢?



赞(0)    操作        顶端 
yang.liu
注册用户
等级:少校
经验:1182
发帖:77
精华:1
注册:2014-1-3
状态:离线
发送短消息息给yang.liu 加好友    发送短消息息给yang.liu 发消息
发表于: IP:您无权察看 2014-4-18 9:48:17 | [全部帖] [楼主帖] 3  楼

1. 在嵌入式系统中,有时core dump直接从串口打印出来,结合objdump查找ra和epa地址,运用栈回溯,可以找到程序出错的地方。

2. 在一般Linux系统中,默认是不会产生core dump文件的,通过ulimit -c来查看core dump文件的大小,一般开始是0,可以设置core文件大小,ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。

3. core dump文件输出设置,一般默认是当前目录,可以在/proc/sys/kernel中找到core-user-pid,通过

echo "1" > /proc/sys/kernel/core-user-pid使core文件名加上pid号,还可以用

mkdir -p /root/corefile


echo "/root/corefile/core-%e-%p-%t" > /proc/sys/kernel/core-pattern控制core文件保存位置和文件名格式。

以下是参数列表:
%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 添加命令名

4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.编译时加上-g
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.

gdb [exec file] [core file]


如:

gdb ./test test.core


在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.

5. 给个例子

test.c
void a()
{
      char *p = NULL;
      printf("%d/n", *p);
}
int main()
{
a();
return 0;
}


编译 gcc -g -o test test.c

运行 ./test

报segmentation fault(core dump)

gdb ./test test.core如果生成的是test.core.

开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因。缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置:

ulimit -c unlimited

上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制。

上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程序相同的目录中,并且文件名固定为core。很显然,如果有多个程序产生core文件,或者同一个程序多次崩溃,就会重复覆盖同一个core文件。

我们通过修改kernel的参数,可以指定内核所生成的coredump文件的文件名。例如,Easwy使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件:

echo 'core.%e.%p' > /proc/sys/kernel/core_pattern

这样配置后,产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。

可以在core_pattern模板中使用变量还很多,见下面的列表:

    %% 单个%字符
    %p 所dump进程的进程ID
    %u 所dump进程的实际用户ID
    %g 所dump进程的实际组ID
    %s 导致本次core dump的信号
    %t core dump的时间 (由1970年1月1日计起的秒数)
    %h 主机名
    %e 程序文件名

如果在上述文件名中包含目录分隔符”/“,那么所生成的core文件将会被放到指定的目录中。

需要说明的是,在内核中还有一个与coredump相关的设置,就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1,那么即使core_pattern中没有设置%p,最后生成的core dump文件名仍会加上进程ID。

对所生成的core dump进程分析,需要使用调试工具,例如GDB等

1. 在嵌入式系统中,有时core dump直接从串口打印出来,结合objdump查找ra和epa地址,运用栈回溯,可以找到程序出错的地方。

2. 在一般Linux系统中,默认是不会产生core dump文件的,通过ulimit -c来查看core dump文件的大小,一般开始是0,可以设置core文件大小,ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。

3. core dump文件输出设置,一般默认是当前目录,可以在/proc/sys/kernel中找到core-user-pid,通过

echo "1" > /proc/sys/kernel/core-user-pid使core文件名加上pid号,还可以用

mkdir -p /root/corefile


echo "/root/corefile/core-%e-%p-%t" > /proc/sys/kernel/core-pattern控制core文件保存位置和文件名格式。

以下是参数列表:
%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 添加命令名

4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.编译时加上-g
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.

gdb [exec file] [core file]


如:

gdb ./test test.core


在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.

5. 给个例子

test.c
void a()
{
      char *p = NULL;
      printf("%d/n", *p);
}
int main()
{
a();
return 0;
}


编译 gcc -g -o test test.c

运行 ./test

报segmentation fault(core dump)

gdb ./test test.core如果生成的是test.core.

开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因。缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置:

ulimit -c unlimited

上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制。

上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程序相同的目录中,并且文件名固定为core。很显然,如果有多个程序产生core文件,或者同一个程序多次崩溃,就会重复覆盖同一个core文件。

我们通过修改kernel的参数,可以指定内核所生成的coredump文件的文件名。例如,Easwy使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件:

echo 'core.%e.%p' > /proc/sys/kernel/core_pattern

这样配置后,产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。

可以在core_pattern模板中使用变量还很多,见下面的列表:

    %% 单个%字符
    %p 所dump进程的进程ID
    %u 所dump进程的实际用户ID
    %g 所dump进程的实际组ID
    %s 导致本次core dump的信号
    %t core dump的时间 (由1970年1月1日计起的秒数)
    %h 主机名
    %e 程序文件名

如果在上述文件名中包含目录分隔符”/“,那么所生成的core文件将会被放到指定的目录中。

需要说明的是,在内核中还有一个与coredump相关的设置,就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1,那么即使core_pattern中没有设置%p,最后生成的core dump文件名仍会加上进程ID。

对所生成的core dump进程分析,需要使用调试工具,例如GDB等

1. 在嵌入式系统中,有时core dump直接从串口打印出来,结合objdump查找ra和epa地址,运用栈回溯,可以找到程序出错的地方。

2. 在一般Linux系统中,默认是不会产生core dump文件的,通过ulimit -c来查看core dump文件的大小,一般开始是0,可以设置core文件大小,ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。

3. core dump文件输出设置,一般默认是当前目录,可以在/proc/sys/kernel中找到core-user-pid,通过

echo "1" > /proc/sys/kernel/core-user-pid使core文件名加上pid号,还可以用

mkdir -p /root/corefile


echo "/root/corefile/core-%e-%p-%t" > /proc/sys/kernel/core-pattern控制core文件保存位置和文件名格式。

以下是参数列表:
%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 添加命令名

4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.编译时加上-g
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.

gdb [exec file] [core file]


如:

gdb ./test test.core


在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行

5.开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因。缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置:

ulimit -c unlimited

上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制。

上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程序相同的目录中,并且文件名固定为core。很显然,如果有多个程序产生core文件,或者同一个程序多次崩溃,就会重复覆盖同一个core文件。

我们通过修改kernel的参数,可以指定内核所生成的coredump文件的文件名。例如,Easwy使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件:

echo 'core.%e.%p' > /proc/sys/kernel/core_pattern

这样配置后,产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。

可以在core_pattern模板中使用变量还很多,见下面的列表:

    %% 单个%字符
    %p 所dump进程的进程ID
    %u 所dump进程的实际用户ID
    %g 所dump进程的实际组ID
    %s 导致本次core dump的信号
    %t core dump的时间 (由1970年1月1日计起的秒数)
    %h 主机名
    %e 程序文件名

如果在上述文件名中包含目录分隔符”/“,那么所生成的core文件将会被放到指定的目录中。

需要说明的是,在内核中还有一个与coredump相关的设置,就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1,那么即使core_pattern中没有设置%p,最后生成的core dump文件名仍会加上进程ID。

对所生成的core dump进程分析,需要使用调试工具,例如GDB等。



赞(0)    操作        顶端 
总帖数
3
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论