12_TUXEDO_典型问题

<Insert Picture Here>Tuxedo 典型问题Tuxedo应用内存泄漏（Memory Leak） Tuxedo应用核心转储（Core Dump） Tuxedo应用阻塞Tuxedo应用挂起Tuxedo优化策略Tuxedo应用内存泄漏（Memory Leak）✓问题现象✓原因分析✓解决方法Tuxedo应用核心转储（Core Dump） Tuxedo应用阻塞Tuxedo应用挂起Tuxedo优化策略问题现象•从整个系统的角度看，存在内存泄漏会造成系统的空闲内存不断减小，极端情况下有可能造成操作系统运行缓慢或宕机•从进程角度来看，存在内存泄漏的进程，它的进程空间会不断增加（通过”ps –elf”、AIX的”svmon”查看进程）原因分析•内存泄漏是指程序对于一块动态申请的内存失去了参照指针，造成内存块无法释放的现象•内存泄漏是由于在程序中调用malloc或者类似功能函数申请内存，却没有在程序中调用free或者类似功能函数释放引起的原因分析•应用代码从经验来看，这是内存泄漏问题经常出现的地方。

包括的形式：–忽略对申请的内存释放。

比如在代码开始时申请了一块空间，但是在程序结束时却忽略了去释放此块内存。

–指针使用不当。

在做指针赋值时，没有释放已有的内存空间，就将它指向另一个内存空间。

–数据库游标的使用不当。

在程序中，如果使用了数据库的游标，需要在程序返回时，将游标关闭。

–采用C++编程时，没有正确的调用析构函数原因分析•数据库在客户的项目中，出现过数据库提供的函数存在内存泄漏，如：–Oracle的OCI链接库–Sybase的Open Client的链接库•Tuxedo–C++编写服务端service时，tpreturn跳出析构函数的执行–tpalloc和tprealloc内存的释放不正确•操作系统–C的lib库存在内存泄漏问题解决方法•检查应用代码。

–检查内存的申请和释放是否匹配–检查指针在赋值时，是否释放已有内存空间–检查游标的打开和关闭是否匹配–检查析构函数是否被调用•采用隔离的方法分析代码–对于存在内存泄漏的代码可以采用将代码分段隔离的方法来查找•采用相应的工具软件分析代码–现在有很多的查找内存泄漏的工具。

如dbx、Rational的Purify等•将数据库、中间件和操作系统地相应补丁及时更新解决方法•观察是否存在内存泄漏–通过系统工具top查看系统的可用内存是否持续减少–通过系统工具ps –elf查看进程的内存空间是否超常，如超过100M•查找内存泄漏的进程–在一段时间内，定期收集系统中进程的内存状况；–将收集的结果在Excel中对比，找到哪个进程不断地增长解决方法•确认进程内存泄漏–在Solaris下用pmap监控内存不断增长的进程。

如果[heap]的大小不断增加，说明这个进程有内存泄漏。

–在AIX下用svmon监控内存不断增长的进程。

注意[private]的大小Solaris的pmap的输出$ pmap 2345102905: test00010000 192K r-x--/usr/bin/ksh00040000 8K rwx--/usr/bin/ksh00042000 40K rwx--[ heap ]FF180000 664K r-x--/usr/lib/libc.so.1 FF236000 24K rwx--/usr/lib/libc.so.1 FF23C000 8K rwx--/usr/lib/libc.so.1FF250000 8K rwx--[ anon ]……..FFBFC000 16K rw---[ stack ]total 1880KAIX的svmon的输出# svmon -P 19556Pid Command Inuse Pin Pgspace19556 pacman 3085 1 1580Pid: 19556Command: pacmanSegid Type Description Inuse Pin Pgspace Address Range 9c8 pers /dev/hd2:53289 1 0 0 0..0aaf work lib data 12 0 6 0..1081909 work shared library text 1502 0 7 0..655351eba work private 1568 1 1567 0..1562:65313..65535 16f3 pers code,/dev/lv01:12302 2 0 0 0..1解决方法•调试内存泄漏---隔离法这是最原始的方法，但是比较容易入手。

在隔离时应该：–将程序代码逐步减少，缩小问题的范围–在隔离时，不要替换代码–在隔离时，注意代码的完整解决方法•调试内存泄漏---dbx在Solaris下，用dbx可以对内存泄漏的运行程序进行调试–调试步骤%export LD_PRLOAD=/opt/SUNWspro/lib/librtc.so%dbx –c filename //对程序进行调试(dbx) check –access //打开内存访问调试检查标志(dbx) check –memuse //打开内存使用和内存泄漏检查标志(dbx) run //运行程序(dbx) cont //继续运行程序，将给出内存报告注意：在编译代码时，用-g选项，不要用-O和其他优化选项解决方法•调试内存泄漏---dbx–理解内存泄漏报告•location:泄漏的内存块在那里申请的•addr:泄漏的内存块的地址•size: 泄漏的内存块的大小•stack:调用堆栈的位置–能够监测的内存泄漏错误mel(Memory Leak),air(Adress in Register),aib(Address in Block)解决方法•调试内存泄漏---Rational Purify–自动化的测试工具–可以测试C/C++, VB, Java等语言开发的程序–可作无源码调试解决方法•调试内存泄漏---Rational Purify–设置参数Settings->Default setting->Error and Leaks，选择memory leaks和memory in use选项–调试步骤•选择调试的程序•运行程序，产生结果数据•通过结果数据，找到源代码解决方法•调试内存泄漏---Rational Purify内容提要Tuxedo应用内存泄漏（Memory Leak） Tuxedo应用核心转储（Core Dump）✓问题现象✓原因分析✓解决方法Tuxedo应用阻塞Tuxedo应用挂起Tuxedo优化策略核心转储（Core Dump）问题现象•在Tuxedo的ULOG中会有如下的信息：–LIBTUX_CAT:541: WARN: Server GROUP_XX/30001terminated–LIBTUX_CAT:557: INFO: Server GROUP_XX/30001 being restarted•在操作系统中会产生Core文件前提是操作系统对Core 文件大小无限制（用ulimit –a查看）核心转储（Core Dump）原因分析应用core dump最常见是由于进程内存访问越界造成的。

•内存访问越界是指在对数组或者是指针操作时，访问的地址超出了分配的数据段。

造成这种问题的主要函数如strcpy，sprintf，memcpy，strcat等等；•操作未初始化的空间，比如指针变量没有初始化，就对指针赋值•内存访问越界的结果会造成应用进程异常中止，并在进程的执行目录产生core文件。

解决方法•缓解问题–可以在UBB中配置Restart来暂时缓解S1 GRACE=3600 RESTART=Y MAXGEN=10•解决问题–用调试工具如dbx或者dbxtra调试core文件file core #找到产生core的文件dbx file_name core #产生堆栈信息trace #列出Core的时候的堆栈状况–在AIX下，可以用errpt –a来查看进程堆栈解决方法•编译阶段–在UNIX上，带上“-g”选项编译程序•buildserver –f “-g” –f simpserv.c –o simpserv –s TOUPPER •最终调用CC•可以设置CFLAGS变量–在Windows上，带上“/Zi /Od”选项编译程序•buildserver –f “/Zi /Od” –f simpserv.c –o simpserv –sTOUPPER•最终调用CL–编译时设置“-k”选项，保留Tuxedo应用的main()函数•buildserver –k –f “-g” –f simpserv.c –o simpserv –sTOUPPER解决方法•以tmboot中的-d1选项启动该应用Server$ tmboot -d1 -s simpservINFO: BEA Tuxedo, Version 8.0, 32-bit, Patch Level 153 INFO: Serial #: 650522264137-933467316566, Expiration 2003-07-31, Maxusers 10000INFO: Licensed to: BEA Internal use onlyBooting server processes ...exec simpserv -C dom=simpapp -g 1 -i 1 -u bea-cs -U/home/gpdai/tux/ULOG -m 0 -A :process id=19897 ... Started.1 process started.•注意记下进程号，也可用ps得到解决方法•使用gdb/dbx/dbxtra/vc++等调试工具将硬盘上的可执行文件和内存中的进程绑定在一起调试–gdb simpserv <pid>–dbx simpserv <pid>–dbxtra simpserv <pid>–msdev –p <pid> (Windows)解决方法•打开源代码文件，在想跟踪的语句上设置断点，通常设在SERVICE的入口处，通过单步执行进行调试:(gdb) break TOUPPERBreakpoint 1 at 0x2b90: file simpserv.c, line 56.内容提要Tuxedo应用内存泄漏（Memory Leak） Tuxedo应用核心转储（Core Dump） Tuxedo应用阻塞✓问题现象✓原因分析✓解决方法Tuxedo应用挂起Tuxedo优化策略队列阻塞问题现象•从操作员来看，系统响应缓慢，经常提示操作超时•从系统管理员来看，至少有如下一个状况：–操作系统队列较长（ipcs –qob ）–Tuxedo队列较长（echo pq|tmadmin |sort +4 ）–数据库执行队列较长（informix:onstat –g rea –r 2）原因分析•操作系统队列较长–如果ULOG日志中有LIBTUX的1285由于操作系统队列最大长度太小引起（MSQMNB）；LIBTUX_CAT:1285 WARN: tpreturn message send blocked, will try file transfer–如果ULOG日志中没有LIBTUX的1285可能由于应用过于繁忙或者处理慢引起，需分析Server状况原因分析•Tuxedo队列较长–Server处理缓慢•在配置文件中，增加’-r’参数来统计Server的Service处理时间•在源代码中，增加调试代码。