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。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值