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系统环境

4详细分析 

1）应用运行缓慢

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

2）Core dump

分析core文件，找出dump的具体点：

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

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是否响应缓慢以及网络问题。

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

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

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号，还可以用

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后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.

5. 给个例子

编译 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的设置：

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

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

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

这样配置后，产生的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号，还可以用

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后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.

5. 给个例子

编译 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的设置：

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

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

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

这样配置后，产生的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号，还可以用

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后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行

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

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

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

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

这样配置后，产生的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等。