JAVA问题定位技术

议题线程堆栈解读性能瓶颈分析远程调试内存泄漏检测Java调试技巧

proc工具集系统跟踪命令truss/strace

Corecoreadm进程状态监控prstat网络状态监控netstat磁盘监控iostat

CPU和内存监控vmstat抓包工具其它工具常用工具集线程堆栈－如何输出线程堆栈Windows：在运行java的控制台上按ctrl+break组合键Unix：保留启动java的控制台，使用kill-3<pid>堆栈的作用：线程死锁分析辅助CPU过高分析线程资源不足分析性能瓶颈分析关键线程异常退出启动时进行重定向是一个不错的习惯：run.sh>start.log2>&1线程堆栈－如何解读线程堆栈？wait()——会释放监视锁sleep()——与锁操作无关,继续保持监视锁当一个线程占有一个锁的时候，会打印-locked<0xe7402c48>当该线程正在等待别的线程释放该锁，就会打印:waitingtolock<0xe7402c48>如果代码中有wait()调用的话，首先是locked,然后又会打印-waitingon<0xe7402c48>Wait也sleep的重大区别"--27443-Processor4"daemonprio=5tid=0x599a7520nid=0x1858inObject.wait()[5c9ef000..5c9efd88] atjava.lang.Object.wait(NativeMethod) -waitingon<0x1693d2f8>(aorg.apache.tomcat.util.threads.ThreadPool$ControlRunnable) atjava.lang.Object.wait(Object.java:429) atorg.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:655) -locked<0x1693d2f8>(aorg.apache.tomcat.util.threads.ThreadPool$ControlRunnable) atjava.lang.Thread.run(Thread.java:534)线程堆栈－如何解读线程堆栈？表示该线程锁柱了该锁表示正在线程正停在该对象的wait上面。同时wait会自动释放该锁"smpp02:Sender-108"daemonprio=5tid=0x59a751a0nid=0x13fcwaitingformonitorentry[6066f000..6066fd88] atorg.apache.log4j.Category.callAppenders(Category.java:185) -waitingtolock<0x14fdfe98>(aorg.apache.log4j.spi.RootCategory) atorg.apache.log4j.Category.forcedLog(Category.java:372) atorg.apache.log4j.Category.log(Category.java:864) atorg.apachemons.logging.impl.Log4JLogger.debug(Log4JLogger.java:137) atcom.huawei.uniportalm.base.server.AbstractHandler.send(AbstractHandler.java:407) atcom.huawei.tellin.usr.uc.sendmessage.UCSMPPTransaction.send(UCSMPPTransaction.java:102) atcom.huawei.tellin.usr.uc.sendmessage.UCServerProxy.synSend(UCServerProxy.java:134) atcom.huawei.uniportalxy.SendWorker.run(AbstractProxy.java:666) atcom.huawei.uniportal.utilities.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748) atjava.lang.Thread.run(Thread.java:534)waitingtolock<0x14fdfe98>表示该锁已经被别的线程使用，正在等待该锁被释放线程堆栈－如何解读线程堆栈？

线程堆栈－线程死锁分析FoundoneJava-leveldeadlock:============================="thread1":waitingtolockmonitor0x009fccb4(object0x10032710,a),whichisheldby"thread1""thread1":waitingtolockmonitor0x009fcc94(object0x10032718,a),whichisheldby"thread1"Javastackinformationforthethreadslistedabove:==================================================="thread1":atDeadLockTest.run(DeadLockTest.java:44)-waitingtolock<0x10032710>(a)-locked<0x10032718>(a)atjava.lang.Thread.run(UnknownSource)"thread1":atDeadLockTest.run(DeadLockTest.java:24)-waitingtolock<0x10032718>(a)-locked<0x10032710>(a)atjava.lang.Thread.run(UnknownSource)虚拟机已经告诉我哪里有死锁了，真不错0x10032710和

0x10032718都在等待对方释放，双方都被饿死线程堆栈－用户代码导致CPU过高/热点线程分析首先可以通过kill-3pid(unix下)或<ctrl>+<break>(windows下)获取一个堆栈信息，几分钟之后再获取一个，通过两个堆栈信息对比，将一直在忙的线程找出来。通过分析对应的代码，确认不正常的线程。第一步：通过kill-3java_pid获取当前堆栈信息。第二步：等待一段时间后。再获取一下当前堆栈信息。线程堆栈－用户代码导致CPU过高/热点线程分析第三步：预处理前两个获取的堆栈信息，去掉处于sleeping或waiting的状态的线程。例如如下线程处于wait或者sleep状态，这种线程是不消耗CPU的，因此这些线程可以直接忽略掉，重点关注其它线程："EventManager-Worker-1"daemonprio=8tid=0x00c3ea58nid=0x14ainObject.wait()[935ff000..935ffc28]atjava.lang.Object.wait(NativeMethod)

//该线程已挂起，忽略掉-waitingon<0xbb9515a8>(a)atjava.lang.Object.wait(Object.java:429)第五步：对比预处理后的1，2堆栈信息，找出处于busy状态的线程，该类线程可能是导致cpu高占用率的可疑线程。例如：(下面的是在第一个堆栈信息中找到的处于active活跃状态的线程)"-80-Processor6"daemonprio=5tid=0x013ea770nid=0x143runnable[92eff000..92f019c0]atcom.huawei.u_sysmon.licmgr.LicenseIntf.nativeCheckLicense(NativeMethod)atcom.huawei.u_sysmon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168)atcom.huawei.u_sys.meetingone.sysmgr.ejb.LicRelateBean.updateLic(LicRelateBean.java:80)线程堆栈－用户代码导致CPU过高/热点线程分析同一个线程在第二个堆栈信息中仍处于活跃状态。"-80-Processor6"daemonprio=5tid=0x013ea770nid=0x143runnable[92eff000..92f019c0]atcom.huawei.u_sysmon.licmgr.LicenseIntf.nativeCheckLicense(NativeMethod)atcom.huawei.u_sysmon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168)atcom.huawei.u_sys.meetingone.sysmgr.ejb.LicRelateBean.updateLic(LicRelateBean.java:80)两次打印堆栈该线程一直在运行，说明该线程已运行了5分钟，请在代码中检查该线程是否属于长时间运行线程？如果属于暂态线程，如此长时间运行说明可能有死循环等导致的CPU过高。线程堆栈－线程资源不足分析ausedby::unabletocreatenewnativethread;nestedexceptionis::unabletocreatenewnativethreadatorg.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:214)atorg.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)atorg.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)atorg.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)atorg.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)atorg.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.javCausedby::unabletocreatenewnativethreadatjava.lang.Thread.start(NativeMethod)at..KeepAliveCache$1.run(KeepAliveCache.java:89)atjava.security.AccessController.doPrivileged(NativeMethod)at..KeepAliveCache.put(KeepAliveCache.java:75)at..HttpClient.putInKeepAliveCache(HttpClient.java:382)at..HttpClient.finished(HttpClient.java:370)线程资源属于数量受限资源，一般一个Java进程中的线程数量不要过多，如果太多虚拟机会拒绝创建。可以通过打印线程堆栈，检查线程的数量，确认问题。如果确实属于线程数量过多，请更改线程模型设计性能瓶颈分析什么叫高性能？-不同的场合有不同的指标。有的场合高性能意味着用户速度体验，如界面操作。-适合使用OptimizeIt分析还有的场合，高吞吐量意味着高性能，如短信。-适合使用堆栈分析还有的场合是二者的结合，如IP-适合使用堆栈分析性能瓶颈分析－

Java应用的常见性能陷阱不良的架构不恰当的线程同步资源的不恰当使用导致的资源竞争不恰当的虚拟机运行参数缓慢的磁盘/网络IO内存泄漏－过分相信Java的自动垃圾回收机制性能瓶颈分析－性能设计和调优的原则80-20原则:20%的代码消耗了80%的资源，20%的代码执行消耗了80%的时间.当前的性能瓶颈永远只有一处只有解决了当前这一处性能瓶颈，你才知道下一个性能瓶颈在哪里．性能瓶颈是动态的，低负载时不是瓶颈的地方，在高负载时却可能成为瓶颈性能优化是一个持续的过程．折中的艺术：在性能和灵活性之间寻找平衡点找出当前性能瓶颈修改验证以稍高于系统的当前能力的压力进行模拟性能瓶颈分析－性能分析的手段和方法JVM手术刀：线程堆栈剖析内存泄漏X光机：内存泄漏分析虚拟机润滑油：JVM参数调优性能调优百宝箱：性能调优工具性能瓶颈分析手段和方法之一－线程堆栈剖析原理：通过分析JVM线程运行情况，定位性能问题方法：kill-3<pid>(UNIX)ctrl+break(windows)打印出当前的虚拟机的一个运行剖面，进行分析"WorkerThread-8"...inObject.wait()......-locked<0xf14213c8>(aQueue)..."WorkerThread-10"...inObject.wait()......-locked<0xf14213c8>(aQueue)..."WriterThread-3"...inObject.wait()......-locked<0xf14213c8>(aQueue)...能够发现的性能问题：(1)资源争用(2)锁的粒度过大 (3)sleep的滥用适用场合：识别只有在高负载的时候才出现的性能瓶颈。多线程场合不适用的场合：单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。有一种多线程情况下，需要关注：绝大多数线程处于等待状态，请检查是否有关键路径，没有足够的能力产生线程任务，如：在消息分发系统，消息分发一般是一个线程，而处理是多线程，这时候消息分发是瓶颈的话，观察到的线程堆栈就会出现上面的现象。性能瓶颈分析手段和方法之二

－内存泄漏分析Java程序也存在内存泄漏内存泄漏表现

(1)长时间运行之后系统打印OutOfMemory

(2)JVM莫名其妙地CoreDump内存泄漏分析通过OptimizeIt,JProfile等可以观察对象的数量和分配的位置．JVM也提供一些工具监控堆的使用情况，尽量使用。内存泄漏避免

(1)全局集合－在对象不需要的时侯，从集合中移除

(2)缓存–不用的对象及时清理

(3)Runnable对象new了就必须使用线程来Run等性能瓶颈分析手段和方法之三

－虚拟机调优原理：观察垃圾回收情况并且进行调整，使JVM的垃圾回收更加平滑和高效率方法：Java命令行中增加–verbose:gc运行参数[FullGC792332K->412757K(1040896K),8.9157secs][FullGC799898K->221096K(1040896K),5.3018secs]如果每次回收完成后可用的内存持续减少则可能存在内存泄漏。能够发现的性能问题：垃圾回收参数设置不合理导致的严重的性能问题．内存泄漏可以调节的JVM垃圾回收参数IBMJDK：主要参数：-Xconcurrentbackground–Xconcurrentlevel,以及堆大小。SUN，HPJDK主要是-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFractionJVM调优是个系统工程，和运行环境主要是内存配置密切相关，需要酌情配置处理适用场合： 高负载但实时性要求不高的系统，如Web类应用，如移动彩铃应用，以及大容量且实时性要求非常高的系统，比如呼叫类应用。性能瓶颈分析手段和方法之四

－

性能调优工具

OptimizeIt或JProfile－提供全面的内存泄漏分析，函数调用CPU时间和内存占用分析适用场合：（1）单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。不适用的场合：（1）运行期间，同一段代码被不同线程执行时，由于线程是变化的，无法找出对应的线程。（2）大容量应用下出现的瓶颈,因为启动这个工具性能会有几十倍甚至上百倍的的性能下降，难以支撑大容量情况下的测试分析。只有在大容量下出现的锁竞争也许不会出现，频繁的磁盘IO、数据库访问等导致的瓶颈也不会出现。现象不充分暴露，自然也就谈不上分析。性能瓶颈问题产生的源头分析常见架构和设计问题：同步／异步使用不当不合理的负荷分担缺乏必要的缓冲设计并发设计不当－资源抢占,连接池和线程池等应用不当等效率低下的通信方式数据库连接缓存使用不当……常见编码问题String+，getByte()的不恰当使用：很多时侯可以使用StringBuf过大的同步范围ＳＱＬ语句设计不当……JAVA远程调试虚拟机远程调试开关：-Xdebug-Xrunjdwp:transport=dt_socket,server=y,address=%DEBUG_PORT%,suspend=n打开调试开关会对JVM的运行速度有影响，仅在需要的时候才这样做不仅可以调试本机上运行的服务器，还可以调试远程机器suspend设为n时JVM会在打开调试端口后正常启动，若设为y则JVM启动后会等候调试器连接后才继续启动JAVA远程调试 在Eclipse中打开调试配置对话框，双击左边树中RemoteJavaApplication增加一项远程调试配置Project：需要调试的代码所在工程Host：服务器所在机器，可以是打开了调试端口的远程计算机Port：前述打开的调试端口，server的userconfig.bat中的缺省值是3999GC参数/输出解读下列JVM参数可用于获取gc日志-verbose:gc或-Xloggc:filename一些参考资料JAVA内存泄漏检测2.1

java的垃圾回收机制java虚拟机的垃圾回收算法要做两件事情。首先，它必须检测出垃圾对象。其次，它必须回收垃圾对象所使用的堆空间并还给程序。垃圾检测通常通过建立一个根对象的集合并且检查从这些根对象开始的可触及性来实现。如果正在执行的程序可以访问到的根对象和某个对象之间存在引用路径，这个对象就是可触及的。对于程序来说，根对象总是可以访问的。从这些跟对象开始，任何可以被触及的对象都被认为是“活动”对象。无法被触及的对象被认为是垃圾，因为它们不再影响程序的未来执行。2.2

内存泄漏的产生如果系统中存在越来越多的不再影响程序未来执行的对象，且这些对象和根对象之间存在引用路径，内存泄漏产生了。2.3

内存泄漏的消除根据内存泄漏的产生所述。发生内存泄漏要满足如下两个条件：1.系统中存在越来越多的不再影响程序未来执行的对象。2.这些对象和根对象之间存在引用路径。从这两个条件中能很容易找出消除内存泄漏的方法：截断系统中存在的不影响程序未来执行的对象与根对象之间的引用路径。这样，这些对象就成了“垃圾”对象，jvm就能正常回收它们。JAVA内存泄漏检测常见的内存泄露（1）全局HashMap等容器，在对象不需要后没有及时从容器中remove掉（2）Thread只new了，但没有start……Java内存泄漏的初步确定下面是使用GC输出分析内存泄漏的原理:

[GC65.233:[DefNew:12949K->1434K(13824K),0.0122730secs]87703K->76189K(134892K),0.0123500secs]

(87703K->76189K(134892K),87703K表示系统使用了多少内存(我们称之为当前使用内存),76189K表示进行这次垃圾回收之后使用的内存数量(我们称之为垃圾回收后内存),134892K上两个数据相减)

可以按照如下思路分析GC输出,能够初步比较准确地判断系统是否存在内存泄漏:

(1)首先要确保系统已经稳定运行(如初使化等已经完成等)(这个条件很重要)

(2)然后取一个时间段的GC输出作为分析数据，只分析FULLGC的行，以垃圾回收后的值为分析对象

(3)然后根据GC分析内存的使用情况:

A.如果当前使用内存持续增长,而垃圾回收后内存也持续增长,有一直增长到Xmx设置的内存的趋势,

那么这个时侯基本上就可以断定有内存泄漏问题了.

B.如果当前使用内存增长到一个值之后,又能回落,达到一个动态平衡,那么就没有内存泄漏的情况.

[FullGC912526K->614350K(912576K),2.5546922secs][FullGC912526K->623890K(912576K),2.5777505secs][FullGC912575K->625359K(912576K),2.5620272secs][FullGC912575K->648552K(912576K),2.5632979secs][FullGC912532K->688576K(912576K),2.5211377secs][FullGC912532K->714354K(912576K),2.6212585secs][FullGC912538K->784362K(912576K),2.5190768secs]（1）只有FULLGC的行才有分析价值（2）只需要检查完全垃圾后剩余的内存值是否一直再增大。JAVA内存泄漏精确定位借助一些工具，如：OptimizeitJProfiler、JRockit等，甚至可以使用Java虚拟机自带的工具HProf进行问题的定位；使用HProf的方法如下：java-Xrunhprof其它参数要运行的系统main函所在的类具体的参数列表如下：Hprofusage:-Xrunhprof[:help]|[:<option>=<value>,...]OptionNameandValueDescriptionDefault

heap=dump|sites|allheapprofilingallcpu=samples|times|oldCPUusageoffmonitor=y|nmonitorcontentionnformat=a|basciiorbinaryoutputafile=<file>writedatatofilejava.hprof(.txtforascii)net=<host>:<port>senddataoverasocketwritetofiledepth=<size>stacktracedepth4cutoff=<value>outputcutoffpoint0.0001lineno=y|nlinenumberintraces?ythread=y|nthreadintraces?ndoe=y|ndumponexit?ygc_okay=y|nGCokayduringsamplingyExample:java-Xrunhprof:cpu=samples,file=log.txt,depth=3FooClass使用HProf定位内存泄漏问题时，可以通过通过增加参数“heap=sites”来输出堆栈信息到文件中，然后通过分析堆栈信息h和线程信息来判断内存泄漏的位置；JAVA内存泄漏精确定位–OptimizeIt举例在系统运行平稳后，做一次垃圾回收，并进行标记；反复进行可能出现内存泄漏的操作，然后再进行一次垃圾回收，并按照“Diff”列进行排序（点击该列即可，该列表示相对于进行标记时的对象的增加数）；观察并记录那些对象是增加的；重复进行上面的操作，找出一直是增加的对象；这些对象将可能是导致内存泄漏的原因。双击打开一直增加的对象，将显示这些对象是由那些对象创建的JAVA内存泄漏检测-OptimizeIt使用OptimizeIt定位内存泄露确切位置的步骤：（1）系统稳定运行一段时间，即按照从业务逻辑来讲，不应该再有大的内存需求波动。这个非常重要。（2）点击OptimizeIt上的垃圾回收按钮，然后马上再点mark按钮。将当前实际对象的数量作为基准点。（3）过一段时间（如一个小时或者更多）（4）点击OptimizeIt上的垃圾回收按钮，检查是否有大量的对象增加，如果有增加，主要是哪些对象确定可疑范围，通过结合阅读代码进行分析。Unix下调试利器-Proc工具介绍/proc文件系统不是普通意义上的文件系统，它是一个到运行中进程地址空间的访问接口。通过/proc，可以用标准Unix系统调用(比如open()、read()、write()、ioctl()等等)访问进程地址空间。大多数Unix(/Linux)操作系统在带一系列的工具集，借助这些工具，可以对进行进行剖析，从而协助定位相关问题。

Windows下可以使用Taskinfo工具分析类似的内容Linux下直接到/Proc下面，大部分数据可读。可结合lsof进行分析://Proc工具列表pcredpfilespflagsplddpmapprunpsigpstackpstopptimeptreepwaitpwdxplimitProc工具介绍－pstackpstack打印当前进程的每个线程的堆栈信息

9e7932c8scan_info(1516900,15168b4,1516930,b68,800,b1c)+f89e793628parse(1516900,15168b4,1516924,1516930,9e793544,332a8)+e49e78cc90init(1516948,549,1516900,15168b4,1516924,1516930)+1889e78cf54LicFileParseInit(1516948,549,15168b4,1516900,1516924,1516930)+4c9e79d484AdaptiveLMStandAloneInitEx(15168b4,1516930,9e7c8ebc,549,9e7a9df3,9e7a9dfe)+4809e78b04cAdaptiveLMStandAloneInit(1516718,2c6f,9e7c8ebc,549,9e7a9df3,9e7a9dfe)+2c9e78a3e0__1cLLicenseInit6Fpkc1_i_(64df28,64df28,0,7efefeff,81010100,ff00)+2789e78a7c0Java_com_huawei_u_1sys_common_licmgr_LicenseIntf_nativeCheckLicense(ff33a4,932ff308,932ff384,932ff380,70,0)+80f980b96c????????(932ff384,b8,0,bbd7f4d0,0,0)用处：协助定位JNI/本地程序CPU使用过高，线程死锁通过周期打印堆栈，比较前后堆栈，找出一直处于忙的线程，从而定位出可疑代码范围打印的堆栈包含锁对象，通过检查多个线程的锁对象，从而定位出死锁位置代码段的绝对地址偏移量，即在该位置处调用了其它函数函数的参数Proc工具介绍－pstackSolarisAIXpstack=procstackpmap=procmapLinuxpstack=lsstackpmap=pmappfiles=lsofHPNotfoundProc工具介绍－pstacklwp#14/thread#25ff369764__sigprocmask(ff36bf60,0,0,e6181d70,ff37e000,0)+8ff35e110_sigon(e6181d70,ff385930,6,e6180114,e6181d70,6)+d0ff361150_thrp_kill(0,19,6,ff37e000,19,ff2c0450)+f8ff24b900raise(6,0,0,ffffffff,ff2c03bc,4)+40ff2358ecabort(ff2bc000,e6180268,0,fffffff8,4,e6180289)+100fe3c68fc__1cCosFabort6Fl_v_(1,fe4c8000,1,e61802e8,0,e9f90420)+b8fe3c59f0__1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_(ff2c02ac,fe53895c,fe4dc164,fe470ab4,fe4c8000,e6180308)+254fe20a8b4JVM_handle_solaris_signal(0,25d5b8,e6180d90,fe4c8000,b,e6181048)+8ecff36b824__sighndlr(b,e6181048,e6180d90,fe20a8cc,e6181e14,e6181e04)+cff3684d8sigacthandler(b,e6181d70,0,0,0,ff37e000)+708calledfromsignalhandlerwithsignal11(SIGSEGV)e9f90420Java_HelloWorld_displayHelloWorld(25d644,e6181224,e61819b8,0,2,0)+3000090ae4????????(e6181224,e61819b8,25d5b8,fe4c8000,0,109a0)0008dc4c????????(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)pmapoutputsnippet:E95000001184KreadE96800001392KreadE98000004608KreadE9F60000136Kread/write/execE9F900008Kread/exec/home/usera/wls70/solaris/projectWork/lib/libhello.soE9FA00008Kread/write/exec/home/usera/wls70/solaris/projectWork/lib/libhello.soE9FB40008Kread/write/exec

Noticefromthepstackoutputthattheaddresswherethishappenedisate9f90420.Thepmapoutputsnippetshowsthate9f90420fallsbetweenE9F90000andE9FA0000,sotheerrorishappeningsomewherewithinthelibhello.sosharedobject.Proc工具介绍－Pfiles列出该进程打开的文件句柄和socket连接的IO对象

用法：pfiles<pid>

用处：查找文件句柄泄漏465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewS

Currentrlimit:65536filedescriptors0:S_IFCHRmode:0666dev:313,0ino:6815752uid:0gid:3rdev:13,2O_RDONLY|O_LARGEFILE/devices/pseudo/mm@0:null14:S_IFSOCKmode:0666dev:319,0ino:34066uid:0gid:0size:0O_RDWRSOCK_STREAMSO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(49152)

sockname:AF_INETport:4941615:S_IFSOCKmode:0666dev:319,0ino:34064uid:0gid:0size:0O_RDWRSOCK_STREAMSO_SNDBUF(49152),SO_RCVBUF(49152)sockname:AF_INETport:4941546:S_IFREGmode:0644dev:118,8ino:406695uid:0gid:0size:159744O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/c60.dat47:S_IFREGmode:0644dev:118,8ino:406729uid:0gid:0size:8192O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/c81.dat48:S_IFREGmode:0644dev:118,8ino:406733uid:0gid:0size:8192O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/cc0.dat49:S_IFREGmode:0644dev:118,8ino:406734uid:0gid:0size:8192O_RDWR|O_CREAT|O_LARGEFILE/usr/local/uniportal/conf/server/isapdb/seg0/cd1.dat打开的文件该进程允许打开的最多文件句柄数建立的socketProc工具介绍－Pfiles有的时候打印不出具体的文件名：1018:S_IFREGmode:0644dev:291,0ino:335047uid:3221gid:102size:2425O_RDONLY|O_LARGEFILE结合如下命令可以找到打开了哪个文件find.–typef–execls–i{}\;print|grep335047

打开的文件的节点号，如果文件已经被删除，给文件句柄尚未关闭，那么pfiles就无法打印出文件名。Proc工具介绍－Pflags

报告指定进程的状态

用法：pflags<pid>465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewSdatamodel=_ILP32flags=ORPHAN|MSACCT|MSFORK/1:flags=ASLEEPlwp_cond_wait(0x383b0,0x38398,0x0,0x0)sigmask=0x00000004,0x00000000/2:flags=DETACH|ASLEEPlwp_cond_wait(0x3d290,0x3d278,0x0,0x0)sigmask=0x00000004,0x00000000/3:flags=DETACH|ASLEEPlwp_cond_wait(0x3d290,0x3d278,0x0,0x0)sigmask=0x00000004,0x00000000Proc工具介绍－pldd本进程依赖的动态库列举与指定进程相关的所有动态链接库

用法：pldd<pid>

用处：查找使用的是哪一个JNI本地库465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewS/usr/j2se/jre/lib/sparc/server/libjvm.soProc工具介绍－pmap显示指定进程地址空间，包括内存段大小和访问权限设置用法：pmap<pid>

用处：查找是哪个第三方的本地库引起的问题FBF7E0008Krwx-R[anon]FBF9000024Kr-xFBFA60008KrwxFBFB000024Kr-x--/usr/j2se/jre/lib/sparc/libnio.soFBFC40008Krwx--/usr/j2se/jre/lib/sparc/libnio.soFBFD000056Kr-x--/usr/j2se/jre/lib/sparc/libnet.soFBFEC00016Krwx--/usr/j2se/jre/lib/sparc/libnet.so[heap]Theprocessheap.[stack]Theprocessstack.Ifthecommonnameforthemappingisunknown,pmapdisplays[anon]Proc工具介绍－pmap$pmap1126411264:ora_ckpt_hsbill00000001036680007968Kread/write/exec[heap]0000000380000000266240Kread/write/exec/shared[ismshmid=0x64]共享内存FFFFFFFF7C8020008Kread/write/exec[anon]FFFFFFFF7C8140008Kread/write/exec[anon]FFFFFFFF7C8260008Kread/write/exec[anon]FFFFFFFF7CF000008Kread/write[anon]FFFFFFFF7CF6800032Kread/write[anon]FFFFFFFF7D3000008Kread/write/exec[anon]FFFFFFFF7F5000008Kread/write/exec[anon]FFFFFFFF7FFFA00024Kread/write[stack]total337360K计算后台进程使用的内存资源:337360K-266240K=71,120k这就是一个进程所消耗的内存.Proc工具介绍－ptree显示指定进程相关的血统关系

用法：ptree<pid>475/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv476/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv477/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv478/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv479/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv480/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv6038/usr/local/uniportal/apache/bin/solaris/d-f/usr/local/uniportal/conf/serv475派生了476477等进程Proc工具介绍－pwdx显示指定进程当前工作目录

用法：pwdx<pid>root@isap1#ps-ef|grepjavanoaccessXX:+BackgroundCompilation-Xmx256noaccessclasspath/opt/SUNWcacao/lib/cacaroot46510Mar10?47:19/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewSize=64M–root@isap1#pwdx465465:/usr/local/uniportal/binProc工具介绍－ptime统计进程的执行时间

用法：ptimels-ld#ptimels-lddrwxr-xr-x46rootroot1536Mar2719:28.real0.007user0.002sys0.005Proc工具介绍－plimit获取/设置针对每个进程的限制

用法：plimit<pid>

用处：与其它工具配合使用465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewSresourcecurrentmaximumtime(seconds)unlimitedunlimitedfile(blocks)unlimitedunlimiteddata(kbytes)unlimitedunlimitedstack(kbytes)8192unlimitedcoredump(blocks)unlimitedunlimitednofiles(descriptors)6553665536vmemory(kbytes)unlimitedunlimited文件句柄的个数虚拟内存Core文件大小堆的大小Proc工具介绍－pgrep用于代替ps|grep这种操作，不再需要管道介入

用法：pgrep

-lprocessname#pgrep-ljava1948java2469java465javaProc工具介绍－pkill发送一个用户可定义的信号到一个或多个进程

用法：pkill<pid>Proc工具介绍－psig

列出进程对各种信号的处理方式

用法：psig<pid>465:/usr/j2se/jre/bin/java-DMODULE_TYPE=server-Xms900M-Xmx900M-XX:NewSHUPcaught

UserHandlerRESTARTHUP,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,RTMAXINTignoredQUITcaughtUserHandlerRESTARTHUP,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,RTMAXILLcaughtsignalHandlerRESTART,SIGINFOHUP,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,RTMAXTRAPdefaultProc工具介绍－Prun,Pstop,pwait

运行进程，停止进程，等待所有进程退出

用法：prun/pstop/pwaitpid系统跟踪命令truss/strace/dtracetruss跟踪本进程使用的操作系统调用和信号量用法：truss-p2469-vall11:lwp_sigmask(SIG_SETMASK,0x00020000,0x00000000)=0xFFBFFEFF[0x0000FFFF]1:waitid(P_ALL,0,0xFFBFF030,WEXITED|WNOHANG|WNOWAIT)=01:waitid(P_ALL,0,0xFFBFEE88,WEXITED|WTRAPPED)=01:lwp_sigmask(SIG_SETMASK,0x00220000,0x00000000)=0xFFBFFEFF[0x0000FFFF]1:lwp_sigmask(SIG_SETMASK,0x00020000,0x00000000)=0xFFBFFEFF[0x0000FFFF]1:waitid(P_ALL,0,0xFFBFF030,WEXITED|WNOHANG|WNOWAIT)=01:read(1,0x0002F1B4,8192)=01:llseek(1,0,SEEK_CUR)=10061:close(1)=01:open("/etc/svc/volatile/init-next.state",O_WRONLY|O_CREAT|O_TRUNC,0600)=11:write(1,"\0\0\005\0\0\014\0\0\0\0"..,412)=4121:close(1)=01:rename("/etc/svc/volatile/init-next.state","/etc/svc/volatile/init.state")=01:open("/etc/svc/volatile/init-next.state",O_WRONLY|O_CREAT|O_TRUNC,0600)=11:write(1,"\0\0\005\0\0\014\0\0\0\0"..,412)=4121:close(1)=01:rename("/etc/svc/volatile/init-next.state","/etc/svc/volatile/init.state")=01:stat("/etc/inittab",0xFFBFF298)=01:open("/etc/inittab",O_RDONLY)=11:ioctl(1,TCGETA,0xFFBFF054)Err#25ENOTTY1:fstat64(1,0xFFBFF0C8)=01:fstat64(1,0xFFBFEF70)=01:read(1,"#Copyright"..,8192)=1006读文件写文件系统跟踪命令truss/strace/dtrace其它静态工具：sotruss:针对动态库apptrace:针对应用程序Solaris:trussLinux:straceSolars10:Dtrace:功能更加强大系统跟踪命令sotrussroot@isap1#sotrussdatedate->libc.so.1:*atexit(0xff3c020c,0x22000,0x0)date->libc.so.1:*atexit(0x11550,0xff0ecbc0,0xa7bf4)date->libc.so.1:*setlocale(0x6,0x11560,0x0)date->libc.so.1:*textdomain(0x11564,0xff0cf566,0xff340200)date->libc.so.1:*getopt(0x1,0xffbff264,0x11574)date->libc.so.1:*time(0x225c0,0xffbff264,0x22400)date->libc.so.1:*nl_langinfo(0x3a,0xffbff264,0x22400)date->libc.so.1:*localtime(0x225c0,0xe8,0x10cf0)date->libc_psr.so.1:*memcpy(0xffbff1d4,0xff340240,0x24)date->libc.so.1:*strftime(0x225c4,0x400,0xff0d5274)date->libc.so.1:*puts(0x225c4,0x400,0xff0d5274)跟踪共享库的系统调用Core文件管理coreadm管理异常情况下产生的core文件，如文件名和位置等用法：coreadm-optionsroot@isap1#coreadmglobalcorefilepattern:globalcorefilecontent:defaultinitcorefilepattern:coreinitcorefilecontent:defaultglobalcoredumps:disabledper-processcoredumps:enabledglobalsetidcoredumps:disabledper-processsetidcoredumps:disabledglobalcoredumplogging:disabled进程状态监测prstat/topPIDUSERNAMESIZERSSSTATEPRINICETIMECPUPROCESS/NLWP3972root4880K4608Kcpu14900:00:000.1%prstat/1465root1240M899Msleep29100:47:230.0%java/2312469noaccess142M63Msleep5901:20:210.0%java/21109root106M95Msleep5901:09:370.0%picld/104root0K0Ksleep60-2:38:000.0%cluster/10762787root2192K1752Ksleep5900:01:060.0%rpc.rstatd/1305daemon2368K1416Ksleep60-200:00:000.0%lockd/2310root5808K4088Ksleep5900:01:400.0%inetd/4302root2000K1032Ksleep5900:00:010.0%sac/1309root1280K832Ksleep5900:00:110.0%utmpd/12587spmadmin20M9960Ksleep5900:00:000.0%d/1295daemon12M10Msleep5900:00:070.0%nfsmapid/3446root5720K4344Ksleep5900:00:000.0%fmd/11254root7704K2632Ksleep100-0:00:000.0%failfastd/4Total:119processes,1943lwps,loadaverages:0.11,0.11,0.11打印当前的进程状态（CPU，内存使用情况）用法：prstatTop

o:VIRT--VirtualImage(kb)Thetotalamountofvirtualmemoryusedbythetask.Itincludesallcode,dataandsharedlibrariespluspagesthathavebeenswappedout.VIRT=SWAP+RES.p:SWAP--Swappedsize(kb)Theswappedoutportionofatask'stotalvirtualmemoryimage.q:RES--Residentsize(kb)Thenon-swappedphysicalmemoryataskhasused.RES=CODE+DATA.r:CODE--Codesize(kb)Theamountofphysicalmemorydevotedtoexecutablecode,alsoknownasthe'text