JAVA問題定位技術(shù)(B培).ppt

1、JAVA問題定位技術(shù)-常用的手段和工具,Page 2,議題,Page 3,線程堆棧 如何輸出線程堆棧,Windows：在運(yùn)行java的控制臺(tái)上按ctrl+break組合鍵 Unix：保留啟動(dòng)java的控制臺(tái)，使用kill -3 ,堆棧的作用： 線程死鎖分析 輔助CPU過(guò)高分析 線程資源不足分析 性能瓶頸分析 關(guān)鍵線程異常退出,啟動(dòng)時(shí)進(jìn)行重定向是一個(gè)不錯(cuò)的習(xí)慣： 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、線程資源屬于數(shù)量受限資源，一般一個(gè)Java進(jìn)程中的線程數(shù)量不要過(guò)多， 如果太多虛擬機(jī)會(huì)拒絕創(chuàng)建?？梢酝ㄟ^(guò)打印線程堆棧，檢查線程的數(shù)量， 確認(rèn)問題。如果確實(shí)屬于線程數(shù)量過(guò)多，請(qǐng)更改線程模型設(shè)計(jì),Page 12,性能瓶頸分析,什么叫高性能？ -不同的場(chǎng)合有不同的指標(biāo)。 有的場(chǎng)合高性能意味著用戶速度體驗(yàn)，如界面操作。- 適合使用OptimizeIt分析 還有的場(chǎng)合，高吞吐量意味著高性能，如短信。 - 適合使用堆棧分析 還有的場(chǎng)合是二者的結(jié)合，如IP電話- 適合使用堆棧分析,Page 13,性能瓶頸分析 Java應(yīng)用的常見性能陷阱,不良的架構(gòu) 不恰當(dāng)?shù)木€程同步 資源的不恰當(dāng)使用導(dǎo)致的資源競(jìng)爭(zhēng) 不恰當(dāng)?shù)?/p>

6、虛擬機(jī)運(yùn)行參數(shù) 緩慢的磁盤/網(wǎng)絡(luò) IO 內(nèi)存泄漏過(guò)分相信Java的自動(dòng)垃圾回收機(jī)制,Page 14,性能瓶頸分析性能設(shè)計(jì)和調(diào)優(yōu)的原則,80-20原則: 20%的代碼消耗了80%的資源，20%的代碼執(zhí)行消耗了80%的時(shí)間. 當(dāng)前的性能瓶頸永遠(yuǎn)只有一處 只有解決了當(dāng)前這一處性能瓶頸，你才知道下一個(gè)性能瓶頸在哪里 性能瓶頸是動(dòng)態(tài)的，低負(fù)載時(shí)不是瓶 頸 的地 方，在高負(fù)載時(shí)卻可能成為瓶頸 性能優(yōu)化是一個(gè)持續(xù)的過(guò)程 折中的藝術(shù)：在性能和靈活性之間尋找平衡點(diǎn),找出當(dāng)前性能瓶頸,修改,驗(yàn)證,以稍高于系統(tǒng)的當(dāng)前 能力的壓力進(jìn)行模擬,Page 15,性能瓶頸分析性能分析的手段和方法,JVM手術(shù)刀：線程堆棧剖析

7、內(nèi)存泄漏X光機(jī)：內(nèi)存泄漏分析 虛擬機(jī)潤(rùn)滑油：JVM參數(shù)調(diào)優(yōu) 性能調(diào)優(yōu)百寶箱：性能調(diào)優(yōu)工具,Page 16,性能瓶頸分析手段和方法之一線程堆棧剖析,原理：通過(guò)分析JVM線程運(yùn)行情況，定位性能問題 方法：kill -3 (UNIX) ctrl+break (windows) 打印出當(dāng)前的虛擬機(jī)的一個(gè)運(yùn)行剖面，進(jìn)行分析 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) . 能夠發(fā)現(xiàn)的性能問題： (1) 資源爭(zhēng)用 (2) 鎖的粒度過(guò)大 (3) sleep的濫用 適用場(chǎng)合： 識(shí)別只有在高負(fù)載的時(shí)候才出現(xiàn)的性能瓶頸。 多線程場(chǎng)合 不適用的場(chǎng)合： 單操作單線程下的代碼段耗時(shí)分析,如一次界面點(diǎn)擊，感覺遲緩。,有一種多線程情況下，需要關(guān)注： 絕大多數(shù)線程處于等待狀態(tài)，請(qǐng)檢查是否有關(guān)鍵路徑，沒有足夠的能力產(chǎn)生線程任務(wù)，如：在消息分發(fā)系統(tǒng)，消息分發(fā)一般是一個(gè)線程，而處理是多線程，這時(shí)候消息分發(fā)是瓶頸的話，觀察到的線程堆棧就會(huì)出現(xiàn)上面的現(xiàn)象。,Page 17,性能瓶頸分析手段和方法之二 內(nèi)存泄漏分析,Java

9、 程序也存在內(nèi)存泄漏 內(nèi)存泄漏表現(xiàn) (1) 長(zhǎng)時(shí)間運(yùn)行之后系統(tǒng)打印OutOfMemory (2) JVM 莫名其妙地 Core Dump 內(nèi)存泄漏分析 通過(guò)OptimizeIt, JProfile等可以觀察對(duì)象的數(shù)量和分配的位置JVM 也提供一些工具監(jiān)控堆的使用情況，盡量使用。 內(nèi)存泄漏避免 (1) 全局集合 在對(duì)象不需要的時(shí)侯，從集合中移除 (2) 緩存 不用的對(duì)象及時(shí)清理 (3) Runnable對(duì)象new了就必須使用線程來(lái)Run等,Page 18,性能瓶頸分析手段和方法之三 虛擬機(jī)調(diào)優(yōu),原理： 觀察垃圾回收情況并且進(jìn)行調(diào)整，使JVM的垃圾回收更加平滑和高效率 方法：Java 命令行中增加

10、 verbose:gc 運(yùn)行參數(shù) Full GC 792332K-412757K(1040896K), 8.9157secs Full GC 799898K-221096K(1040896K), 5.3018secs 如果每次回收完成后可用的內(nèi)存持續(xù)減少則可能存在內(nèi)存泄漏。 能夠發(fā)現(xiàn)的性能問題： 垃圾回收參數(shù)設(shè)置不合理導(dǎo)致的嚴(yán)重的性能問題 內(nèi)存泄漏 可以調(diào)節(jié)的JVM 垃圾回收參數(shù) IBM JDK：主要參數(shù)： -Xconcurrentbackground Xconcurrentlevel, 以及堆大小。 SUN，HP JDK 主要是 -XX:+UseParNewGC -XX:+UseConcMa

11、rkSweepGC -XX:CMSInitiatingOccupancyFraction JVM調(diào)優(yōu)是個(gè)系統(tǒng)工程，和運(yùn)行環(huán)境主要是內(nèi)存配置密切相關(guān)，需要酌情配置處理 適用場(chǎng)合： 高負(fù)載但實(shí)時(shí)性要求不高的系統(tǒng)，如 Web 類應(yīng)用，如移動(dòng)彩鈴應(yīng)用，以及大容量且實(shí)時(shí)性要求非常高的系統(tǒng)，比如呼叫類應(yīng)用。,Page 19,性能瓶頸分析手段和方法之四 性能調(diào)優(yōu)工具,OptimizeIt或JProfile 提供全面的內(nèi)存泄漏分析，函數(shù)調(diào)用CPU時(shí)間和內(nèi)存占用分析 適用場(chǎng)合： （1） 單操作單線程下的代碼段耗時(shí)分析,如一次界面點(diǎn)擊，感覺遲緩。 不適用的場(chǎng)合： （1）運(yùn)行期間，同一段代碼被不同線程執(zhí)行時(shí)，由于線

12、程是變化的，無(wú)法找出對(duì)應(yīng)的線程。 （2）大容量應(yīng)用下出現(xiàn)的瓶頸, 因?yàn)閱?dòng)這個(gè)工具性能會(huì)有幾十倍甚至上百倍的的性能下降，難以支撐大容量情況下的測(cè)試分析。只有在大容量下出現(xiàn)的鎖競(jìng)爭(zhēng)也許不會(huì)出現(xiàn)，頻繁的磁盤IO、數(shù)據(jù)庫(kù)訪問等導(dǎo)致的瓶頸也不會(huì)出現(xiàn)?，F(xiàn)象不充分暴露，自然也就談不上分析。,Page 20,性能瓶頸問題產(chǎn)生的源頭分析,常見架構(gòu)和設(shè)計(jì)問題： 同步異步使用不當(dāng) 不合理的負(fù)荷分擔(dān) 缺乏必要的緩沖設(shè)計(jì) 并發(fā)設(shè)計(jì)不當(dāng)資源搶占, 連接池和線程池等應(yīng)用不當(dāng)?shù)?效率低下的通信方式 數(shù)據(jù)庫(kù)連接緩存使用不當(dāng) 常見編碼問題 String +，getByte()的不恰當(dāng)使用：很多時(shí)侯可以使用StringBuf 過(guò)

13、大的同步范圍 語(yǔ)句設(shè)計(jì)不當(dāng) ,Page 21,JAVA 遠(yuǎn)程調(diào)試,虛擬機(jī)遠(yuǎn)程調(diào)試開關(guān)： -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=%DEBUG_PORT%,suspend=n,打開調(diào)試開關(guān)會(huì)對(duì)JVM的運(yùn)行速度有影響，僅在需要的時(shí)候才這樣做,不僅可以調(diào)試本機(jī)上運(yùn)行的服務(wù)器，還可以調(diào)試遠(yuǎn)程機(jī)器,suspend設(shè)為n時(shí)JVM會(huì)在打開調(diào)試端口后正常啟動(dòng)，若設(shè)為y則JVM啟動(dòng)后會(huì)等候調(diào)試器連接后才繼續(xù)啟動(dòng),Page 22,JAVA 遠(yuǎn)程調(diào)試,在Eclipse中打開調(diào)試配置對(duì)話框，雙擊左邊樹中Remote Java Application

14、增加一項(xiàng)遠(yuǎn)程調(diào)試配置,Project：需要調(diào)試的代碼所在工程 Host：服務(wù)器所在機(jī)器，可以是打開了調(diào)試端口的遠(yuǎn)程計(jì)算機(jī) Port：前述打開的調(diào)試端口，server的userconfig.bat中的缺省值是3999,Page 23,GC參數(shù)/輸出解讀,下列JVM參數(shù)可用于獲取gc日志 -verbose:gc 或 -Xloggc:filename 一些參考資料 ,Page 24,JAVA 內(nèi)存泄漏檢測(cè),2.1 java的垃圾回收機(jī)制 java虛擬機(jī)的垃圾回收算法要做兩件事情。首先，它必須檢測(cè)出垃圾對(duì)象。 其次，它必須回收垃圾對(duì)象所使用的堆空間并還給程序。 垃圾檢測(cè)通常通過(guò)建立一個(gè)根對(duì)象的集合并且

15、檢查從這些根對(duì)象開始的可觸及性來(lái)實(shí)現(xiàn)。 如果正在執(zhí)行的程序可以訪問到的根對(duì)象和某個(gè)對(duì)象之間存在引用路徑，這個(gè)對(duì)象就是可觸及的。 對(duì)于程序來(lái)說(shuō)，根對(duì)象總是可以訪問的。從這些跟對(duì)象開始， 任何可以被觸及的對(duì)象都被認(rèn)為是“活動(dòng)”對(duì)象。無(wú)法被觸及的對(duì)象被認(rèn)為是垃圾， 因?yàn)樗鼈儾辉儆绊懗绦虻奈磥?lái)執(zhí)行。 2.2 內(nèi)存泄漏的產(chǎn)生 如果系統(tǒng)中存在越來(lái)越多的不再影響程序未來(lái)執(zhí)行的對(duì)象，且這些對(duì)象和根對(duì)象之間存在引用路徑， 內(nèi)存泄漏產(chǎn)生了。 2.3 內(nèi)存泄漏的消除 根據(jù) 內(nèi)存泄漏的產(chǎn)生 所述。發(fā)生內(nèi)存泄漏要滿足如下兩個(gè)條件： 1. 系統(tǒng)中存在越來(lái)越多的不再影響程序未來(lái)執(zhí)行的對(duì)象。 2. 這些對(duì)象和根對(duì)象之間存在引

16、用路徑。 從這兩個(gè)條件中能很容易找出消除內(nèi)存泄漏的方法：截?cái)嘞到y(tǒng)中存在的不影響程序未來(lái)執(zhí)行的對(duì)象與 根對(duì)象之間的引用路徑。這樣，這些對(duì)象就成了“垃圾”對(duì)象，jvm就能正?；厥账鼈儭?Page 25,JAVA 內(nèi)存泄漏檢測(cè),常見的內(nèi)存泄露 （1） 全局HashMap等容器，在對(duì)象不需要后沒有及時(shí)從容器中remove掉 （2） Thread只new了，但沒有start ,Page 26,Java內(nèi)存泄漏的初步確定,下面是使用GC輸出分析內(nèi)存泄漏的原理: GC 65.233: DefNew: 12949K-1434K(13824K), 0.0122730 secs 87703K-76189K(134

17、892K), 0.0123500 secs (87703K-76189K(134892K), 87703K表示系統(tǒng)使用了多少內(nèi)存(我們稱之為當(dāng)前使用內(nèi)存), 76189K表示進(jìn)行這次垃圾回收之后使用的內(nèi)存數(shù)量(我們稱之為垃圾回收后內(nèi)存),134892K上兩個(gè)數(shù)據(jù)相減) 可以按照如下思路分析GC輸出,能夠初步比較準(zhǔn)確地判斷系統(tǒng)是否存在內(nèi)存泄漏: (1) 首先要確保系統(tǒng)已經(jīng)穩(wěn)定運(yùn)行(如初使化等已經(jīng)完成等) (這個(gè)條件很重要) (2) 然后取一個(gè)時(shí)間段的GC 輸出作為分析數(shù)據(jù)，只分析FULL GC的行，以垃圾回收后的值為分析對(duì)象 (3) 然后根據(jù)GC分析內(nèi)存的使用情況: A. 如果當(dāng)前使用內(nèi)存持續(xù)增

18、長(zhǎng), 而垃圾回收后內(nèi)存也持續(xù)增長(zhǎng), 有一直增長(zhǎng)到Xmx設(shè)置的內(nèi)存的趨勢(shì), 那么這個(gè)時(shí)侯基本上就可以斷定有內(nèi)存泄漏問題了. B. 如果當(dāng)前使用內(nèi)存增長(zhǎng)到一個(gè)值之后,又能回落, 達(dá)到一個(gè)動(dòng)態(tài)平衡, 那么就沒有內(nèi)存泄漏的情況.,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的行才有分析價(jià)值 （2） 只需要檢查完全垃圾后剩余的內(nèi)存值是否一直再增大。,Page 27,JAVA 內(nèi)存泄漏精確定位,借助一些工具，如：Optimizeit JProfiler、JRockit等， 甚至可以使用Java虛擬機(jī)自帶的工具HProf進(jìn)行問題的定位；使用

20、HProf的方法如下： java -Xrunhprof 其它參數(shù) 要運(yùn)行的系統(tǒng)main函所在的類 具體的參數(shù)列表如下： 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定位內(nèi)存泄漏問題時(shí)，可以通過(guò)通過(guò)增加參數(shù)“heap=sites”來(lái)輸出堆棧信息到文件中， 然后通過(guò)分析堆棧信息h和線程信息來(lái)判斷內(nèi)存泄漏的位置；,Page 28,JAVA 內(nèi)存泄漏精確定位 OptimizeIt舉例,在系統(tǒng)運(yùn)行平穩(wěn)后，做一次垃圾回收，并進(jìn)行標(biāo)記；反復(fù)進(jìn)行可能出現(xiàn)內(nèi)存泄漏的操作，然后再進(jìn)行一次垃圾回收，并按照“Diff”列進(jìn)行排序（點(diǎn)擊該列即可，該列表示相對(duì)于進(jìn)行標(biāo)記時(shí)的對(duì)象的增加數(shù)）；觀察并記錄那些對(duì)象是增加的；重復(fù)進(jìn)行上面的操作，找出一直是增加的對(duì)象；這些對(duì)象將可能是導(dǎo)致內(nèi)存泄漏的

23、原因。 雙擊打開一直增加的對(duì)象，將顯示這些對(duì)象是由那些對(duì)象創(chuàng)建的,Page 29,JAVA 內(nèi)存泄漏檢測(cè)-OptimizeIt,使用OptimizeIt定位內(nèi)存泄露確切位置的步驟： （1） 系統(tǒng)穩(wěn)定運(yùn)行一段時(shí)間，即按照從業(yè)務(wù)邏輯來(lái)講， 不應(yīng)該再有大的內(nèi)存需求波動(dòng)。這個(gè)非常重要。 （2） 點(diǎn)擊OptimizeIt上的垃圾回收按鈕，然后馬上再點(diǎn)mark按鈕。 將當(dāng)前實(shí)際對(duì)象的數(shù)量作為基準(zhǔn)點(diǎn)。 （3） 過(guò)一段時(shí)間（如一個(gè)小時(shí)或者更多） （4） 點(diǎn)擊OptimizeIt上的垃圾回收按鈕，檢查是否有大量的對(duì)象增加， 如果有增加，主要是哪些對(duì)象 確定可疑范圍，通過(guò)結(jié)合閱讀代碼進(jìn)行分析。,Page 30,U

24、nix下調(diào)試?yán)?Proc工具介紹,/proc文件系統(tǒng)不是普通意義上的文件系統(tǒng)，它是一個(gè)到運(yùn)行中進(jìn)程地址空間的訪問接口。通過(guò)/proc，可以用標(biāo)準(zhǔn)Unix系統(tǒng)調(diào)用(比如open()、read()、write()、ioctl()等等)訪問進(jìn)程地址空間。 大多數(shù)Unix(/Linux)操作系統(tǒng)在帶一系列的工具集，借助這些工具，可以對(duì)進(jìn)行進(jìn)行剖析，從而協(xié)助定位相關(guān)問題。,Windows下可以使用Taskinfo工具分析類似的內(nèi)容 Linux下直接到/Proc下面，大部分?jǐn)?shù)據(jù)可讀。 可結(jié)合lsof進(jìn)行分析,Page 31,Proc工具列表,pcred pfiles pflags pldd pmap p

25、run psig,pstack pstop ptime ptree pwait pwdx plimit,Page 32,Proc工具介紹pstack,pstack 打印當(dāng)前進(jìn)程的每個(gè)線程的堆棧信息,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),用處： 協(xié)助定位JNI/本地程序CPU使用過(guò)高，線程死鎖,通過(guò)周期打印堆棧，比較前后堆棧，找出一直處于忙的線程，從而定位出可

28、疑代碼范圍,打印的堆棧包含鎖對(duì)象，通過(guò)檢查多個(gè)線程的鎖對(duì)象，從而定位出死鎖位置,代碼段的絕對(duì)地址,偏移量，即在該位置處調(diào)用了其它函數(shù),函數(shù)的參數(shù),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,列出該進(jìn)程打開的文件句柄和socket連接的IO對(duì)象 用法：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,打開的文件,該進(jìn)程允許打開的最多文件句柄數(shù),建立的socket,Page 36,Proc工具介紹Pfiles,有的時(shí)候打印不出具體的文件名： 1018: S_IFREG mode:0644 dev:291,0 ino:335047 uid:3221 gid:102 size:2425 O_RDONLY|O_LARGEFILE 結(jié)合如下命令可以找到打開了哪個(gè)文件 find . type f exec ls i ; print | grep 335047,打開的文件的節(jié)點(diǎn)號(hào)，如果文件已經(jīng)被刪除，給文件句柄尚未關(guān)閉，那么pfiles

40、就無(wú)法打印出文件名。,Page 37,Proc工具介紹Pflags,報(bào)告指定進(jìn)程的狀態(tài) 用法：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,本進(jìn)程依賴的動(dòng)態(tài)庫(kù),列舉與指定進(jìn)程相關(guān)的所有動(dòng)態(tài)鏈接庫(kù) 用法： pldd 用處：查找使用的是哪一個(gè)JNI本地庫(kù),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,顯示指定進(jìn)程地址空間，包括內(nèi)存段

43、大小和訪問權(quán)限設(shè)置 用法：pmap 用處：查找是哪個(gè)第三方的本地庫(kù)引起的問題,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 共享內(nèi)存 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 計(jì)算后臺(tái)進(jìn)程使用的內(nèi)存資源: 337360K - 266240K = 71,120k 這就是一個(gè)進(jìn)程所消耗的內(nèi)存.,Page 41,Proc工具介紹ptree,顯示指定進(jìn)程相關(guān)的血統(tǒng)關(guān)系

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等進(jìn)程,Page 42,Proc工具介紹pwdx,顯示指定進(jìn)程當(dāng)前工作目錄 用法： 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,統(tǒng)計(jì)進(jìn)程的執(zhí)行時(shí)間 用法：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,獲取/設(shè)置針對(duì)每個(gè)進(jìn)程的限制 用法： 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,文件句柄的個(gè)數(shù),虛擬內(nèi)存,Core文件大小,堆的大小,Page 45,Proc工具介紹pgrep,用于代替ps | grep這種操作，不再需要管道介入 用法： pgrep -l processname,# pgrep -l java 1948 java 2469 java 465 java,Page 46,Proc工具介紹pkill,發(fā)送一個(gè)用戶可定義的信號(hào)到一個(gè)或多個(gè)

56、進(jìn)程 用法： pkill ,Page 47,Proc工具介紹psig,列出進(jìn)程對(duì)各種信號(hào)的處理方式 用法：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