JAVA问题定位技术(B培).ppt

1、JAVA问题定位技术-常用的手段和工具,Page 2,议题,Page 3,线程堆栈 如何输出线程堆栈,Windows：在运行java的控制台上按ctrl+break组合键 Unix：保留启动java的控制台，使用kill -3 ,堆栈的作用： 线程死锁分析 辅助CPU过高分析 线程资源不足分析 性能瓶颈分析 关键线程异常退出,启动时进行重定向是一个不错的习惯： run.sh start.log 2 nested exception is: java.lang.OutOfMemoryError: unable to create new native thread at org.jboss.ej

2、b.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:214) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(Security

3、Interceptor.java:111) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.jav,Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start(Native Met

4、hod) at .www.http.KeepAliveCache$1.run(KeepAliveCache.java:89) at java.security.AccessController.doPrivileged(Native Method) at .www.http.KeepAliveCache.put(KeepAliveCache.java:75) at .www.http.HttpClient.putInKeepAliveCache(HttpClient.java:382) at .www.http.HttpClient.finished(HttpClient.java:370),

5、线程资源属于数量受限资源，一般一个Java进程中的线程数量不要过多， 如果太多虚拟机会拒绝创建。可以通过打印线程堆栈，检查线程的数量， 确认问题。如果确实属于线程数量过多，请更改线程模型设计,Page 12,性能瓶颈分析,什么叫高性能？ -不同的场合有不同的指标。 有的场合高性能意味着用户速度体验，如界面操作。- 适合使用OptimizeIt分析 还有的场合，高吞吐量意味着高性能，如短信。 - 适合使用堆栈分析 还有的场合是二者的结合，如IP电话- 适合使用堆栈分析,Page 13,性能瓶颈分析 Java应用的常见性能陷阱,不良的架构 不恰当的线程同步 资源的不恰当使用导致的资源竞争 不恰当的

6、虚拟机运行参数 缓慢的磁盘/网络 IO 内存泄漏过分相信Java的自动垃圾回收机制,Page 14,性能瓶颈分析性能设计和调优的原则,80-20原则: 20%的代码消耗了80%的资源，20%的代码执行消耗了80%的时间. 当前的性能瓶颈永远只有一处 只有解决了当前这一处性能瓶颈，你才知道下一个性能瓶颈在哪里 性能瓶颈是动态的，低负载时不是瓶 颈 的地 方，在高负载时却可能成为瓶颈 性能优化是一个持续的过程 折中的艺术：在性能和灵活性之间寻找平衡点,找出当前性能瓶颈,修改,验证,以稍高于系统的当前 能力的压力进行模拟,Page 15,性能瓶颈分析性能分析的手段和方法,JVM手术刀：线程堆栈剖析

7、内存泄漏X光机：内存泄漏分析 虚拟机润滑油：JVM参数调优 性能调优百宝箱：性能调优工具,Page 16,性能瓶颈分析手段和方法之一线程堆栈剖析,原理：通过分析JVM线程运行情况，定位性能问题 方法：kill -3 (UNIX) ctrl+break (windows) 打印出当前的虚拟机的一个运行剖面，进行分析 WorkerThread-8 . in Object.wait() . . - locked (a Queue) . WorkerThread-10 . in Object.wait() . . - locked (a Queue) . WriterThread-3 . in Obj

8、ect.wait() . . - locked (a Queue) . 能够发现的性能问题： (1) 资源争用 (2) 锁的粒度过大 (3) sleep的滥用 适用场合： 识别只有在高负载的时候才出现的性能瓶颈。 多线程场合 不适用的场合： 单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。,有一种多线程情况下，需要关注： 绝大多数线程处于等待状态，请检查是否有关键路径，没有足够的能力产生线程任务，如：在消息分发系统，消息分发一般是一个线程，而处理是多线程，这时候消息分发是瓶颈的话，观察到的线程堆栈就会出现上面的现象。,Page 17,性能瓶颈分析手段和方法之二 内存泄漏分析,Java

9、 程序也存在内存泄漏 内存泄漏表现 (1) 长时间运行之后系统打印OutOfMemory (2) JVM 莫名其妙地 Core Dump 内存泄漏分析 通过OptimizeIt, JProfile等可以观察对象的数量和分配的位置JVM 也提供一些工具监控堆的使用情况，尽量使用。 内存泄漏避免 (1) 全局集合 在对象不需要的时侯，从集合中移除 (2) 缓存 不用的对象及时清理 (3) Runnable对象new了就必须使用线程来Run等,Page 18,性能瓶颈分析手段和方法之三 虚拟机调优,原理： 观察垃圾回收情况并且进行调整，使JVM的垃圾回收更加平滑和高效率 方法：Java 命令行中增加

10、 verbose:gc 运行参数 Full GC 792332K-412757K(1040896K), 8.9157secs Full GC 799898K-221096K(1040896K), 5.3018secs 如果每次回收完成后可用的内存持续减少则可能存在内存泄漏。 能够发现的性能问题： 垃圾回收参数设置不合理导致的严重的性能问题 内存泄漏 可以调节的JVM 垃圾回收参数 IBM JDK：主要参数： -Xconcurrentbackground Xconcurrentlevel, 以及堆大小。 SUN，HP JDK 主要是 -XX:+UseParNewGC -XX:+UseConcMa

11、rkSweepGC -XX:CMSInitiatingOccupancyFraction JVM调优是个系统工程，和运行环境主要是内存配置密切相关，需要酌情配置处理 适用场合： 高负载但实时性要求不高的系统，如 Web 类应用，如移动彩铃应用，以及大容量且实时性要求非常高的系统，比如呼叫类应用。,Page 19,性能瓶颈分析手段和方法之四 性能调优工具,OptimizeIt或JProfile 提供全面的内存泄漏分析，函数调用CPU时间和内存占用分析 适用场合： （1） 单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。 不适用的场合： （1）运行期间，同一段代码被不同线程执行时，由于线

12、程是变化的，无法找出对应的线程。 （2）大容量应用下出现的瓶颈, 因为启动这个工具性能会有几十倍甚至上百倍的的性能下降，难以支撑大容量情况下的测试分析。只有在大容量下出现的锁竞争也许不会出现，频繁的磁盘IO、数据库访问等导致的瓶颈也不会出现。现象不充分暴露，自然也就谈不上分析。,Page 20,性能瓶颈问题产生的源头分析,常见架构和设计问题： 同步异步使用不当 不合理的负荷分担 缺乏必要的缓冲设计 并发设计不当资源抢占, 连接池和线程池等应用不当等 效率低下的通信方式 数据库连接缓存使用不当 常见编码问题 String +，getByte()的不恰当使用：很多时侯可以使用StringBuf 过

13、大的同步范围 语句设计不当 ,Page 21,JAVA 远程调试,虚拟机远程调试开关： -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=%DEBUG_PORT%,suspend=n,打开调试开关会对JVM的运行速度有影响，仅在需要的时候才这样做,不仅可以调试本机上运行的服务器，还可以调试远程机器,suspend设为n时JVM会在打开调试端口后正常启动，若设为y则JVM启动后会等候调试器连接后才继续启动,Page 22,JAVA 远程调试,在Eclipse中打开调试配置对话框，双击左边树中Remote Java Application

14、增加一项远程调试配置,Project：需要调试的代码所在工程 Host：服务器所在机器，可以是打开了调试端口的远程计算机 Port：前述打开的调试端口，server的userconfig.bat中的缺省值是3999,Page 23,GC参数/输出解读,下列JVM参数可用于获取gc日志 -verbose:gc 或 -Xloggc:filename 一些参考资料 ,Page 24,JAVA 内存泄漏检测,2.1 java的垃圾回收机制 java虚拟机的垃圾回收算法要做两件事情。首先，它必须检测出垃圾对象。 其次，它必须回收垃圾对象所使用的堆空间并还给程序。 垃圾检测通常通过建立一个根对象的集合并且

15、检查从这些根对象开始的可触及性来实现。 如果正在执行的程序可以访问到的根对象和某个对象之间存在引用路径，这个对象就是可触及的。 对于程序来说，根对象总是可以访问的。从这些跟对象开始， 任何可以被触及的对象都被认为是“活动”对象。无法被触及的对象被认为是垃圾， 因为它们不再影响程序的未来执行。 2.2 内存泄漏的产生 如果系统中存在越来越多的不再影响程序未来执行的对象，且这些对象和根对象之间存在引用路径， 内存泄漏产生了。 2.3 内存泄漏的消除 根据 内存泄漏的产生 所述。发生内存泄漏要满足如下两个条件： 1. 系统中存在越来越多的不再影响程序未来执行的对象。 2. 这些对象和根对象之间存在引

16、用路径。 从这两个条件中能很容易找出消除内存泄漏的方法：截断系统中存在的不影响程序未来执行的对象与 根对象之间的引用路径。这样，这些对象就成了“垃圾”对象，jvm就能正常回收它们。,Page 25,JAVA 内存泄漏检测,常见的内存泄露 （1） 全局HashMap等容器，在对象不需要后没有及时从容器中remove掉 （2） Thread只new了，但没有start ,Page 26,Java内存泄漏的初步确定,下面是使用GC输出分析内存泄漏的原理: GC 65.233: DefNew: 12949K-1434K(13824K), 0.0122730 secs 87703K-76189K(134

17、892K), 0.0123500 secs (87703K-76189K(134892K), 87703K表示系统使用了多少内存(我们称之为当前使用内存), 76189K表示进行这次垃圾回收之后使用的内存数量(我们称之为垃圾回收后内存),134892K上两个数据相减) 可以按照如下思路分析GC输出,能够初步比较准确地判断系统是否存在内存泄漏: (1) 首先要确保系统已经稳定运行(如初使化等已经完成等) (这个条件很重要) (2) 然后取一个时间段的GC 输出作为分析数据，只分析FULL GC的行，以垃圾回收后的值为分析对象 (3) 然后根据GC分析内存的使用情况: A. 如果当前使用内存持续增

18、长, 而垃圾回收后内存也持续增长, 有一直增长到Xmx设置的内存的趋势, 那么这个时侯基本上就可以断定有内存泄漏问题了. B. 如果当前使用内存增长到一个值之后,又能回落, 达到一个动态平衡, 那么就没有内存泄漏的情况.,Full GC 912526K-614350K(912576K), 2.5546922 secs Full GC 912526K-623890K(912576K), 2.5777505 secs Full GC 912575K-625359K(912576K), 2.5620272 secs Full GC 912575K-648552K(912576K), 2.563297

19、9 secs Full GC 912532K-688576K(912576K), 2.5211377 secs Full GC 912532K-714354K(912576K), 2.6212585 secs Full GC 912538K-784362K(912576K), 2.5190768 secs,（1） 只有FULL GC的行才有分析价值 （2） 只需要检查完全垃圾后剩余的内存值是否一直再增大。,Page 27,JAVA 内存泄漏精确定位,借助一些工具，如：Optimizeit JProfiler、JRockit等， 甚至可以使用Java虚拟机自带的工具HProf进行问题的定位；使用

20、HProf的方法如下： java -Xrunhprof 其它参数 要运行的系统main函所在的类 具体的参数列表如下： Hprof usage: -Xrunhprof:help|:=, . Option Name and Value Description Default - - - heap=dump|sites|all heap profiling all cpu=samples|times|old CPU usage off monitor=y|n monitor contention n format=a|b ascii or binary output a file= write d

21、ata to file java.hprof(.txt for ascii) net=: send data over a socket write to file depth= stack trace depth 4 cutoff= output cutoff point 0.0001 lineno=y|n line number in traces? y thread=y|n thread in traces? n doe=y|n dump on exit? y gc_okay=y|n GC okay during sampling y Example: java -Xrunhprof:c

22、pu=samples,file=log.txt,depth=3 FooClass 使用HProf定位内存泄漏问题时，可以通过通过增加参数“heap=sites”来输出堆栈信息到文件中， 然后通过分析堆栈信息h和线程信息来判断内存泄漏的位置；,Page 28,JAVA 内存泄漏精确定位 OptimizeIt举例,在系统运行平稳后，做一次垃圾回收，并进行标记；反复进行可能出现内存泄漏的操作，然后再进行一次垃圾回收，并按照“Diff”列进行排序（点击该列即可，该列表示相对于进行标记时的对象的增加数）；观察并记录那些对象是增加的；重复进行上面的操作，找出一直是增加的对象；这些对象将可能是导致内存泄漏的

23、原因。 双击打开一直增加的对象，将显示这些对象是由那些对象创建的,Page 29,JAVA 内存泄漏检测-OptimizeIt,使用OptimizeIt定位内存泄露确切位置的步骤： （1） 系统稳定运行一段时间，即按照从业务逻辑来讲， 不应该再有大的内存需求波动。这个非常重要。 （2） 点击OptimizeIt上的垃圾回收按钮，然后马上再点mark按钮。 将当前实际对象的数量作为基准点。 （3） 过一段时间（如一个小时或者更多） （4） 点击OptimizeIt上的垃圾回收按钮，检查是否有大量的对象增加， 如果有增加，主要是哪些对象 确定可疑范围，通过结合阅读代码进行分析。,Page 30,U

24、nix下调试利器-Proc工具介绍,/proc文件系统不是普通意义上的文件系统，它是一个到运行中进程地址空间的访问接口。通过/proc，可以用标准Unix系统调用(比如open()、read()、write()、ioctl()等等)访问进程地址空间。 大多数Unix(/Linux)操作系统在带一系列的工具集，借助这些工具，可以对进行进行剖析，从而协助定位相关问题。,Windows下可以使用Taskinfo工具分析类似的内容 Linux下直接到/Proc下面，大部分数据可读。 可结合lsof进行分析,Page 31,Proc工具列表,pcred pfiles pflags pldd pmap p

25、run psig,pstack pstop ptime ptree pwait pwdx plimit,Page 32,Proc工具介绍pstack,pstack 打印当前进程的每个线程的堆栈信息,9e7932c8 scan_info (1516900, 15168b4, 1516930, b68, 800, b1c) + f8 9e793628 parse (1516900, 15168b4, 1516924, 1516930, 9e793544, 332a8) + e4 9e78cc90 init (1516948, 549, 1516900, 15168b4, 1516924, 1516

26、930) + 188 9e78cf54 LicFileParseInit (1516948, 549, 15168b4, 1516900, 1516924, 1516930) + 4c 9e79d484 AdaptiveLMStandAloneInitEx (15168b4, 1516930, 9e7c8ebc, 549, 9e7a9df3, 9e7a9dfe) + 480 9e78b04c AdaptiveLMStandAloneInit (1516718, 2c6f, 9e7c8ebc, 549, 9e7a9df3, 9e7a9dfe) + 2c 9e78a3e0 _1cLLicenseI

27、nit6Fpkc1_i_ (64df28, 64df28, 0, 7efefeff, 81010100, ff00) + 278 9e78a7c0 Java_com_huawei_u_1sys_common_licmgr_LicenseIntf_nativeCheckLicense (ff33a4, 932ff308, 932ff384, 932ff380, 70, 0) + 80 f980b96c ? (932ff384, b8, 0, bbd7f4d0, 0, 0),用处： 协助定位JNI/本地程序CPU使用过高，线程死锁,通过周期打印堆栈，比较前后堆栈，找出一直处于忙的线程，从而定位出可

28、疑代码范围,打印的堆栈包含锁对象，通过检查多个线程的锁对象，从而定位出死锁位置,代码段的绝对地址,偏移量，即在该位置处调用了其它函数,函数的参数,Page 33,Proc工具介绍pstack,Solaris AIX pstack = procstack pmap = procmap Linux pstack = lsstack pmap = pmap pfiles=lsof HP Not found,Page 34,Proc工具介绍pstack,- lwp# 14 / thread# 25 - ff369764 _sigprocmask (ff36bf60, 0, 0, e6181d70, f

29、f37e000, 0) + 8 ff35e110 _sigon (e6181d70, ff385930, 6, e6180114, e6181d70, 6) + d0 ff361150 _thrp_kill (0, 19, 6, ff37e000, 19, ff2c0450) + f8 ff24b900 raise (6, 0, 0, ffffffff, ff2c03bc, 4) + 40 ff2358ec abort (ff2bc000, e6180268, 0, fffffff8, 4, e6180289) + 100 fe3c68fc _1cCosFabort6Fl_v_ (1, fe4

30、c8000, 1, e61802e8, 0, e9f90420) + b8 fe3c59f0 _1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_ (ff2c02ac, fe53895c, fe4dc164, fe470ab4, fe4c8000, e6180308) + 254 fe20a8b4 JVM_handle_solaris_signal (0, 25d5b8, e6180d90, fe4c8000, b, e6181048) + 8ec ff36b824 _sighndlr (b, e6181048, e6180d90, f

31、e20a8cc, e6181e14, e6181e04) + c ff3684d8 sigacthandler (b, e6181d70, 0, 0, 0, ff37e000) + 708 - called from signal handler with signal 11 (SIGSEGV) - e9f90420 Java_HelloWorld_displayHelloWorld (25d644, e6181224, e61819b8, 0, 2, 0) + 30 00090ae4 ? (e6181224, e61819b8, 25d5b8, fe4c8000, 0, 109a0) 000

32、8dc4c ? (e61812c4, ffffffff, ffffffff, 97400, 4, e61811b8) 0008dc4c ? (e618135c, e61819b8, fe4c8000, 99600, c, e6181250) 0008dc4c ? (e61813ec, f76a2f90, e618147c, 99600, c, e61812f8) 0008ddb4 ? (e618147c, f68578b8, 0, 99974, c, e6181388) 0008ddd8 ? (e618154c, e61815c8, e61815cc, 99974, 4, e6181410)

33、- pmap output snippet: . E9500000 1184K read E9680000 1392K read E9800000 4608K read E9F60000 136K read/write/exec E9F90000 8K read/exec /home/usera/wls70/solaris/projectWork/lib/libhello.so E9FA0000 8K read/write/exec /home/usera/wls70/solaris/projectWork/lib/libhello.so E9FB4000 8K read/write/exec

34、 E9FC0000 120K read/exec /usr/lib/libelf.so.1 E9FEE000 8K read/write/exec /usr/lib/libelf.so.1 . Notice from the pstack output that the address where this happened is at e9f90420. The pmap output snippet shows that e9f90420 falls between E9F90000 and E9FA0000, so the error is happening somewhere wit

35、hin the libhello.so shared object.,Page 35,Proc工具介绍Pfiles,列出该进程打开的文件句柄和socket连接的IO对象 用法：pfiles 用处：查找文件句柄泄漏,465: /usr/j2se/jre/bin/java -DMODULE_TYPE=server -Xms900M -Xmx900M -XX:NewS Current rlimit: 65536 file descriptors 0: S_IFCHR mode:0666 dev:313,0 ino:6815752 uid:0 gid:3 rdev:13,2 O_RDONLY|O_LA

36、RGEFILE /devices/pseudo/mm0:null 14: S_IFSOCK mode:0666 dev:319,0 ino:34066 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152) sockname: AF_INET port: 49416 15: S_IFSOCK mode:0666 dev:319,0 ino:34064 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_SNDBUF(49152),SO_

37、RCVBUF(49152) sockname: AF_INET port: 49415 46: S_IFREG mode:0644 dev:118,8 ino:406695 uid:0 gid:0 size:159744 O_RDWR|O_CREAT|O_LARGEFILE /usr/local/uniportal/conf/server/isapdb/seg0/c60.dat 47: S_IFREG mode:0644 dev:118,8 ino:406729 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE /usr/loca

38、l/uniportal/conf/server/isapdb/seg0/c81.dat 48: S_IFREG mode:0644 dev:118,8 ino:406733 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE /usr/local/uniportal/conf/server/isapdb/seg0/cc0.dat 49: S_IFREG mode:0644 dev:118,8 ino:406734 uid:0 gid:0 size:8192 O_RDWR|O_CREAT|O_LARGEFILE /usr/local/uniporta

39、l/conf/server/isapdb/seg0/cd1.dat,打开的文件,该进程允许打开的最多文件句柄数,建立的socket,Page 36,Proc工具介绍Pfiles,有的时候打印不出具体的文件名： 1018: S_IFREG mode:0644 dev:291,0 ino:335047 uid:3221 gid:102 size:2425 O_RDONLY|O_LARGEFILE 结合如下命令可以找到打开了哪个文件 find . type f exec ls i ; print | grep 335047,打开的文件的节点号，如果文件已经被删除，给文件句柄尚未关闭，那么pfiles

40、就无法打印出文件名。,Page 37,Proc工具介绍Pflags,报告指定进程的状态 用法：pflags ,465: /usr/j2se/jre/bin/java -DMODULE_TYPE=server -Xms900M -Xmx900M -XX:NewS data model = _ILP32 flags = ORPHAN|MSACCT|MSFORK /1: flags = ASLEEP lwp_cond_wait(0 x383b0,0 x38398,0 x0,0 x0) sigmask = 0 x00000004,0 x00000000 /2: flags = DETACH|ASLEE

41、P lwp_cond_wait(0 x3d290,0 x3d278,0 x0,0 x0) sigmask = 0 x00000004,0 x00000000 /3: flags = DETACH|ASLEEP lwp_cond_wait(0 x3d290,0 x3d278,0 x0,0 x0) sigmask = 0 x00000004,0 x00000000,Page 38,Proc工具介绍pldd,本进程依赖的动态库,列举与指定进程相关的所有动态链接库 用法： pldd 用处：查找使用的是哪一个JNI本地库,465: /usr/j2se/jre/bin/java -DMODULE_TYPE

42、=server -Xms900M -Xmx900M -XX:NewS /lib/libthread.so.1 /lib/libdl.so.1 /lib/libc.so.1 /platform/sun4u-us3/lib/libc_psr.so.1 /usr/j2se/jre/lib/sparc/server/libjvm.so /usr/lib/libCrun.so.1 /lib/libsocket.so.1 /lib/libnsl.so.1 /lib/libm.so.1 /usr/lib/libsched.so.1,Page 39,Proc工具介绍 pmap,显示指定进程地址空间，包括内存段

43、大小和访问权限设置 用法：pmap 用处：查找是哪个第三方的本地库引起的问题,FBF7E000 8K rwx-R anon FBF90000 24K r-x- /lib/librt.so.1 FBFA6000 8K rwx- /lib/librt.so.1 FBFB0000 24K r-x- /usr/j2se/jre/lib/sparc/libnio.so FBFC4000 8K rwx- /usr/j2se/jre/lib/sparc/libnio.so FBFD0000 56K r-x- /usr/j2se/jre/lib/sparc/libnet.so FBFEC000 16K rwx

44、- /usr/j2se/jre/lib/sparc/libnet.so, heap The process heap. stack The process stack. If the common name for the mapping is unknown, pmap displays anon ,Page 40,Proc工具介绍 pmap,$ pmap 11264 11264: ora_ckpt_hsbill 0000000100000000 53824K read/exec /opt/oracle/product/9.2.0/bin/oracle 000000010358E000 87

45、2K read/write/exec /opt/oracle/product/9.2.0/bin/oracle 0000000103668000 7968K read/write/exec heap 0000000380000000 266240K read/write/exec/shared ism shmid=0 x64 共享内存 FFFFFFFF7C802000 8K read/write/exec anon FFFFFFFF7C814000 8K read/write/exec anon FFFFFFFF7C826000 8K read/write/exec anon FFFFFFFF

46、7CD00000 24K read/exec /usr/lib/sparcv9/nss_files.so.1 FFFFFFFF7CE06000 8K read/write/exec /usr/lib/sparcv9/nss_files.so.1 FFFFFFFF7CF00000 8K read/write anon FFFFFFFF7CF68000 32K read/write anon FFFFFFFF7D000000 16K read/exec /usr/platform/sun4u/lib/sparcv9/libc_psr.so.1 FFFFFFFF7D100000 16K read/e

47、xec /usr/lib/sparcv9/libmp.so.2 FFFFFFFF7D204000 8K read/write/exec /usr/lib/sparcv9/libmp.so.2 FFFFFFFF7D300000 8K read/write/exec anon FFFFFFFF7D400000 88K read/exec /usr/lib/sparcv9/libm.so.1 FFFFFFFF7D516000 8K read/write/exec /usr/lib/sparcv9/libm.so.1 FFFFFFFF7D600000 8K read/exec /usr/lib/spa

48、rcv9/libkstat.so.1 FFFFFFFF7D702000 8K read/write/exec /usr/lib/sparcv9/libkstat.so.1 FFFFFFFF7F200000 8K read/exec /opt/oracle/product/9.2.0/lib/libodmd9.so FFFFFFFF7F300000 8K read/write/exec /opt/oracle/product/9.2.0/lib/libodmd9.so FFFFFFFF7F400000 8K read/exec /usr/lib/sparcv9/libdl.so.1 FFFFFF

49、FF7F500000 8K read/write/exec anon FFFFFFFF7F600000 152K read/exec /usr/lib/sparcv9/ld.so.1 FFFFFFFF7F724000 16K read/write/exec /usr/lib/sparcv9/ld.so.1 FFFFFFFF7FFFA000 24K read/write stack total 337360K 计算后台进程使用的内存资源: 337360K - 266240K = 71,120k 这就是一个进程所消耗的内存.,Page 41,Proc工具介绍ptree,显示指定进程相关的血统关系

50、用法：ptree ,475 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv 476 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv 477 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv 478 /usr/local/uniportal/apache/bin/so

51、laris/httpd -f /usr/local/uniportal/conf/serv 479 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv 480 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv 6038 /usr/local/uniportal/apache/bin/solaris/httpd -f /usr/local/uniportal/conf/serv,4

52、75派生了476 477等进程,Page 42,Proc工具介绍pwdx,显示指定进程当前工作目录 用法： pwdx ,rootisap1 # ps -ef | grep java noaccess 1948 1 0 Feb 16 ? 37:49 /usr/jdk/instances/jdk1.5.0/bin/java -server -XX:+BackgroundCompilation -Xmx256 noaccess 2469 2451 0 Feb 16 ? 80:17 /usr/jdk/jdk1.5.0_01/bin/java -Xms4M -Xmx64M -classpath /opt

53、/SUNWcacao/lib/caca root 465 1 0 Mar 10 ? 47:19 /usr/j2se/jre/bin/java -DMODULE_TYPE=server -Xms900M -Xmx900M -XX:NewSize=64M rootisap1 # pwdx 465 465: /usr/local/uniportal/bin,Page 43,Proc工具介绍ptime,统计进程的执行时间 用法：ptime ls -ld,# ptime ls -ld drwxr-xr-x 46 root root 1536 Mar 27 19:28 . real 0.007 user

54、0.002 sys 0.005,Page 44,Proc工具介绍plimit,获取/设置针对每个进程的限制 用法： plimit 用处：与其它工具配合使用,465: /usr/j2se/jre/bin/java -DMODULE_TYPE=server -Xms900M -Xmx900M -XX:NewS resource current maximum time(seconds) unlimited unlimited file(blocks) unlimited unlimited data(kbytes) unlimited unlimited stack(kbytes) 8192 un

55、limited coredump(blocks) unlimited unlimited nofiles(descriptors) 65536 65536 vmemory(kbytes) unlimited unlimited,文件句柄的个数,虚拟内存,Core文件大小,堆的大小,Page 45,Proc工具介绍pgrep,用于代替ps | grep这种操作，不再需要管道介入 用法： pgrep -l processname,# pgrep -l java 1948 java 2469 java 465 java,Page 46,Proc工具介绍pkill,发送一个用户可定义的信号到一个或多个

56、进程 用法： pkill ,Page 47,Proc工具介绍psig,列出进程对各种信号的处理方式 用法：psig ,465: /usr/j2se/jre/bin/java -DMODULE_TYPE=server -Xms900M -Xmx900M -XX:NewS HUP caught UserHandler RESTART HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,X

57、FSZ,WAITING,LWP,FREEZE,THAW,LOST,XRES,JVM1,JVM2,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX INT ignored QUIT caught UserHandler RESTART HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CLD,PWR,WINCH,URG,POLL,TSTP,CONT,TTIN,TTOU,VTALRM,PROF,XCPU,XFSZ,WAITING,LWP,FREEZE,THAW,LOST,XRES,JVM1,JVM2,RTMIN,RTMIN+1,RTMIN+2,RTMIN+3,RTMAX-3,RTMAX-2,RTMAX-1,RTMAX ILL caught signalHandler RESTART,SIGINFO HUP,INT,QUIT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,CL