oracle+tuxedo+4c,Tuxedo典型问题.ppt

《Tuxedo典型问题.ppt》由会员分享，可在线阅读，更多相关《Tuxedo典型问题.ppt(40页珍藏版)》请在人人文库网上搜索。

1、BEA Tuxedo 典型问题,BEA 客户服务部,BEA Tuxedo 典型问题,Tuxedo应用内存泄露 ( Memory Leak ) Tuxedo应用核心转储 ( Core Dump ) Tuxedo应用阻塞 Tuxedo应用挂起,Tuxedo应用内存泄露(Memory Leak),问题现象 从整个系统的角度看，存在内存泄露会造成系统的空闲内存不断减小，最终将造成系统宕机； 从进程角度来看，存在内存泄露的进程，它的进程空间会不断增加(通过”ps elf”、AIX的”svmon”查看进程),原因分析 内存泄露是指程序对于一块动态申请的内存失去了参照指针，造成内存块无法释放的现象 内存泄露。

2、是由于在程序中调用malloc或者类似功能的函数申请内存，却没有在程序中调用free或者类似功能的函数释放内存引起的,Tuxedo应用内存泄露(Memory Leak),原因分析 应用代码 从经验来看，这是内存泄露问题的主要原因。包括的形式： 忽略对申请的内作释放。比如在代码开始时申请了一块空间，但是在程序借宿时却忽略了去释放此块内存； 指针使用不当。在做指针赋值时，没有释放已有的内存空间，就将它指向另一个内存空间； 数据库游标的使用不当。在程序中，如果使用了数据库的游标，需要在程序返回时，将游标关闭； 在采用C+编程时，没有正确的调用析构函数,Tuxedo应用内存泄露(Memory Leak。

3、),原因分析 数据库 在客户的项目中，出现过数据库提供的函数存在内存泄露，如： Oracle的OCI连接库 Sybase的Open Client的连接库 Tuxedo 操作系统,Tuxedo应用内存泄露(Memory Leak),解决方案 检查应用代码。 检查内存的申请和释放是否匹配 检查指针在赋值时，是否释放已有内存空间； 检查游标的打开和关闭是否匹配 检查析构函数是否被调用 采用隔离的方法分析代码 对于存在内存泄露的代码可以采用将代码分段隔离的方法来查找 采用相应的工具软件分析代码 现在有很多的查找内存泄露的工具。如dbx、Rational的Purify等 将数据库、中间件和操作系统地相应。

4、补丁及时更新,Tuxedo应用内存泄露(Memory Leak),解决办法 是否存在内存泄露 通过系统工具top查看系统的可用内存是否持续减少 通过系统工具ps elf查看进程的内存空间是否超常，如超过100M 查找内存泄露的进程 在一段时间内，定期收集系统中进程的内存状况； 将收集的结果在Excel中对比，找到那个进程在增长,Tuxedo应用内存泄露(Memory Leak),解决办法 确认进程内存泄露 在Solaris下 用pmap监控内存不断增长的进程。如果heap的大小不断增加，说明这个进程有内存泄露。 在AIX下 用svmon监控内存不断增长的进程。注意private的大小,Tuxe。

5、do应用内存泄露(Memory Leak),Tuxedo应用内存泄露(Memory Leak),Solaris的pmap的输出 $ pmap 2345 102905: test 00010000 192K r-x- /usr/bin/ksh 00040000 8K rwx- /usr/bin/ksh 00042000 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.1 FF250000 8K rwx。

6、- anon . FF3B0000 8K rwx- anon FF3C0000 152K r-x- /usr/lib/ld.so.1 FF3F6000 8K rwx- /usr/lib/ld.so.1 FFBFC000 16K rw- stack total 1880K,Tuxedo应用内存泄露(Memory Leak),AIX的svmon的输出 # svmon -P 19556 Pid Command Inuse Pin Pgspace 19556 pacman 3085 1 1580 Pid: 19556 Command: pacman Segid Type Description Inu。

7、se Pin Pgspace Address Range 9c8 pers /dev/hd2:53289 1 0 0 0.0 aaf work lib data 12 0 6 0.1081 909 work shared library text 1502 0 7 0.65535 1eba work private 1568 1 1567 0.1562:65313.65535 16f3 pers code,/dev/lv01:12302 2 0 0 0.1,解决办法 调试内存泄露-隔离法 这是最原始的方法，但是比较容易入手。在隔离时应该： 将程序代码逐步减少，缩小问题的范围； 在隔离时，不要替。

8、换代码； 在隔离时，注意代码的完整；,Tuxedo应用内存泄露(Memory Leak),解决办法 调试内存泄露-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选项，不要用-。

9、O和其他优化选项,Tuxedo应用内存泄露(Memory Leak),解决办法 调试内存泄露-dbx 理解内存泄露报告 location:泄露的内存块在那里申请的 addr:泄露的内存块的地址 size: 泄露的内存块的大小 stack:调用堆栈的位置 能够监测的内存泄露错误 mel(Memory Leak),air(Adress in Register),aib(Address in Block),Tuxedo应用内存泄露(Memory Leak),解决办法 调试内存泄露-Rational Purify 自动化的测试工具 可以测试C/C+, VB, Java等语言开发的程序 可作无源码调试,。

10、Tuxedo应用内存泄露(Memory Leak),解决办法 调试内存泄露-Rational Purify 设置参数 Settings-Default setting-Error and Leaks， 选择memory leaks和memory in use选项 调试步骤 选择调试的程序 运行程序，产生结果数据 通过结果数据，找到源代码,Tuxedo应用内存泄露(Memory Leak),Tuxedo应用内存泄露(Memory Leak),解决办法 调试内存泄露-Rational Purify,BEA Tuxedo 典型问题,Tuxedo应用内存泄露 ( Memory Leak ) Tuxed。

11、o应用核心转储 ( Core Dump ) Tuxedo应用阻塞 Tuxedo应用挂起,Tuxedo应用核心转储( Core Dump ),问题现象 在Tuxedo的ULOG中会有如下的信息： LIBTUX_CAT:541: WARN: Server GROUP_XX/30001 terminated LIBTUX_CAT:557: INFO: Server GROUP_XX/30001 being restarted 在操作系统中会产生Core文件 前提是操作系统对Core 文件大小无限制(用ulimit a查看),Tuxedo应用核心转储( Core Dump ),原因分析 Tuxedo应。

12、用核心转储是由于进程内存访问越界造成的。 内存访问越界是指在对数组或者是指针操作时，访问的地址超出了分配的数据段。造成这种问题的主要函数如strcpy，sprintf，memcpy，strcat等等； 操作未初始化的空间，比如指针变量没有初始化，就对指针赋值 内存访问越界的结果会造成应用进程异常中止，并在进程的执行目录产生core文件。,Tuxedo应用核心转储( Core Dump ),解决方案 缓解问题 可以在UBB中配置Restart来暂时缓解 S1 GRACE=3600 RESTART=Y MAXGEN=10 解决问题 用调试工具如dbx或者dbxtra调试core文件 file co。

13、re #找到产生core的文件 dbx file_name core #产生堆栈信息 trace #列出Core的时候的堆栈状况 在AIX下，可以用errpt a来做查看进程堆栈,Tuxedo应用核心转储( Core Dump ),解决方案 检查系统对于Core文件的设置 检查系统和用户对Core文件的限制ulimit -c 对于Solaris,在文件 /etc/system中，检查 core dump 大小的设置, set sys:coredumpsize=0 对于Linux, core dumps 缺省时被取消的,检查 /etc/security/limits.conf文件 对于HPUX,。

14、 检查用户进程的数据段的大小,set maxdsiz 为 134M 检查系统对于用户的磁盘空间的限制 测试是否能够产生core文件：gcore pid,Tuxedo应用核心转储( Core Dump ),调试方法 编译阶段 在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 s TOUPPER 最终调用CL 编译。

15、时设置“-k”选项，保留Tuxedo应用的main()函数 buildserver k f “-g” f simpserv.c o simpserv s TOUPPER,Tuxedo应用核心转储( Core Dump ),调试方法 以tmboot中的-d1选项启动该应用Server $ tmboot -d1 -s simpserv INFO: BEA Tuxedo, Version 8.0, 32-bit, Patch Level 153 INFO: Serial #: 650522264137-933467316566, Expiration 2003-07-31, Maxusers 100。

16、00 INFO: Licensed to: BEA Internal use only Booting 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查,Tuxedo应用核心转储( Core Dump ),调试方法 使用gdb/dbx/dbxtra/vc+等调试工具将硬盘上的可执行文件和内存中的进程绑定在一起调试 gdb。

17、 simpserv dbx simpserv dbxtra simpserv msdev p (Windows),Tuxedo应用核心转储( Core Dump ),调试方法 打开源代码文件，在想跟踪的语句上设置断点，通常设在SERVICE的入口处，通过单步执行进行调试: (gdb) break TOUPPER Breakpoint 1 at 0 x2b90: file simpserv.c, line 56.,Tuxedo应用核心转储( Core Dump ),调试方法 用来分析core文件的工具一般是没有的 你需要下载如下的工具： If available also use: pflags。

18、 ,Tuxedo应用核心转储( Core Dump ),调试方法 用pstack调试,Example pstack output: core core of 20956: /wwsl/sharedInstalls/solaris/wls70sp2/jdk131_06/bin/./bin/sparc/nativ- lwp# 14 / thread# 25 -ff369764 __sigprocmask (ff36bf60, 0, 0, e6181d70, ff37e000, 0) + 8ff35e110 _sigon (e6181d70, ff385930, 6, e6180114, e6181。

19、d70, 6) + d0ff361150 _thrp_kill (0, 19, 6, ff37e000, 19, ff2c0450) + f8ff24b900 raise (6, 0, 0, ffffffff, ff2c03bc, 4) + 40ff2358ec abort (ff2bc000, e6180268, 0, fffffff8, 4, e6180289) + 100fe3c68fc __1cCosFabort6Fl_v_ (1, fe4c8000, 1, e61802e8, 0, e9f90420) + b8fe3c59f0 __1cCosbBhandle_unexpected_e。

20、xception6FpnGThread_ipCpv_v_ (ff2c02ac, fe53895c, fe4dc164, fe470ab4, fe4c8000, e6180308) + 254fe20a8b4 JVM_handle_solaris_signal (0, 25d5b8, e6180d90, fe4c8000, b, e6181048) + 8ecff36b824 __sighndlr (b, e6181048, e6180d90, fe20a8cc, e6181e14, e6181e04) + cff3684d8 sigacthandler (b, e6181d70, 0, 0, 。

21、0, ff37e000) + 708- called from signal handler with signal 11 (SIGSEGV) -e9f90420 Java_HelloWorld_displayHelloWorld (25d644, e6181224, e61819b8, 0, 2, 0) + 3000090ae4 ? (e6181224, e61819b8, 25d5b8, fe4c8000, 0, 109a0).,Tuxedo应用核心转储( Core Dump ),调试方法 pmap 提供进程空间的信息 用来决定是在那里发生的Coredump.,Example pmap o。

22、utput: .E9500000 1184K readE9680000 1392K readE9800000 4608K readE9F60000 136K read/write/execE9F90000 8K read/exec /home/usera/wls70/solaris/projectWork/lib/libhello.soE9FA0000 8K read/write/exec /home/usera/wls70/solaris/projectWork/lib/libhello.soE9FB4000 8K read/write/execE9FC0000 120K read/exec。

23、 /usr/lib/libelf.so.1E9FEE000 8K read/write/exec /usr/lib/libelf.so.1.,BEA Tuxedo 典型问题,Tuxedo应用内存泄露 ( Memory Leak ) Tuxedo应用核心转储 ( Core Dump ) Tuxedo应用阻塞 Tuxedo应用挂起,Tuxedo应用阻塞,问题现象 从操作员来看，系统响应缓慢，经常提示操作超时 从系统管理员来看，至少有如下一个状况： 操作系统队列较长( ipcs qob ) Tuxedo队列较长 ( echo pq|tmadmin |sort +4) 数据库执行队列较长 (infor。

24、mix:onstat g rea r 2),Tuxedo应用阻塞,原因分析 操作系统队列较长 如果ULOG日志中有LIBTUX的1285 由于操作系统队列最大长度太小引起(MSQMNB)； LIBTUX_CAT:1285 WARN: tpreturn message send blocked, will try file transfer 如果ULOG日志中没有LIBTUX的1285 可能由于应用过于繁忙或者处理慢引起，需分析Server状况；,Tuxedo应用阻塞,原因分析 Tuxedo队列较长 Server处理缓慢 在配置文件中，增加-r参数来统计Server的Service处理时间； 在。

25、源代码中，增加调试代码。在日志中，分段打出处理时间； Server处理繁忙 如果数据库处理不忙，说明是Server配置不合理或者是处理慢； 如果数据库处理忙，进一步检查应用代码和数据库配置； Server经常发生Core Dump Server经常Core Dump也会造成队列长。参考Core Dump的处理,Tuxedo应用阻塞,原因分析 数据库队列长 应用代码或者数据库设计存在缺陷。例如： 代码没有用索引、模糊查询大量数据或跨多表操作。需集成商主导解决； 应用的库设计不合理，如将大量记录放入一张表。需集成商主导解决； 数据库的配置不当引起。需要数据厂商主导解决；,Tuxedo应用阻塞,解决。

26、办法 应用阻塞原因复杂，需要结合应用做具体的分析和解决。 调整IPC的参数 msgmnb,msgmax,msgtql 调整TCP/IP的参数(ndd) tcp_time_wait_interval,tcp_conn_req_max_q, tcp_ip_abort_interval,tcp_keepalive_interval 合理配置Server 通过对应用系统的观察和统计，合理的配置Server的数量 采用MSSQ 合理配置Service和Server 根据Service的处理时间长短和业务相关性，配置Server; 优化应用代码 优化数据库设置,BEA Tuxedo 典型问题,Tuxedo。

27、应用内存泄露 ( Memory Leak ) Tuxedo应用核心转储 ( Core Dump ) Tuxedo应用阻塞 Tuxedo应用挂起,Tuxedo应用挂起,问题现象 从操作员角度来看，挂起的这种业务无法作 从管理员角度来看，相应的Server一直在处理一笔业务 Server处理完的请求数不变 ( echo psr|tmadmin |grep server) Server一直在处理一个请求 ( echo psr|tmadmin |grep server),Tuxedo应用挂起,原因分析 Server代码中有死循环 对数据的访问长时间无法完成 网络连接意外断开,Tuxedo应用挂起,解决方案 缓解问题： 设置service超时 解决问题： 采用truss查看进程在做什么 通过数据库工具查看进程在数据库端的操作,How business becomes e-business。