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

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

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

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

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

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

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

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

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

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

16、用路徑。 從這兩個條件中能很容易找出消除內(nèi)存泄漏的方法：截斷系統(tǒng)中存在的不影響程序未來執(zhí)行的對象與 根對象之間的引用路徑。這樣，這些對象就成了“垃圾”對象，jvm就能正?；厥账鼈儭?Page 25,JAVA 內(nèi)存泄漏檢測,常見的內(nèi)存泄露 （1） 全局HashMap等容器，在對象不需要后沒有及時從容器中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)存(我們稱之為當前使用內(nèi)存), 76189K表示進行這次垃圾回收之后使用的內(nèi)存數(shù)量(我們稱之為垃圾回收后內(nèi)存),134892K上兩個數(shù)據(jù)相減) 可以按照如下思路分析GC輸出,能夠初步比較準確地判斷系統(tǒng)是否存在內(nèi)存泄漏: (1) 首先要確保系統(tǒng)已經(jīng)穩(wěn)定運行(如初使化等已經(jīng)完成等) (這個條件很重要) (2) 然后取一個時間段的GC 輸出作為分析數(shù)據(jù)，只分析FULL GC的行，以垃圾回收后的值為分析對象 (3) 然后根據(jù)GC分析內(nèi)存的使用情況: A. 如果當前使用內(nèi)存持續(xù)增

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

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

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

24、nix下調(diào)試利器-Proc工具介紹,/proc文件系統(tǒng)不是普通意義上的文件系統(tǒng)，它是一個到運行中進程地址空間的訪問接口。通過/proc，可以用標準Unix系統(tǒng)調(diào)用(比如open()、read()、write()、ioctl()等等)訪問進程地址空間。 大多數(shù)Unix(/Linux)操作系統(tǒng)在帶一系列的工具集，借助這些工具，可以對進行進行剖析，從而協(xié)助定位相關(guān)問題。,Windows下可以使用Taskinfo工具分析類似的內(nèi)容 Linux下直接到/Proc下面，大部分數(shù)據(jù)可讀。 可結(jié)合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),用處： 協(xié)助定位JNI/本地程序CPU使用過高，線程死鎖,通過周期打印堆棧，比較前后堆棧，找出一直處于忙的線程，從而定位出可

28、疑代碼范圍,打印的堆棧包含鎖對象，通過檢查多個線程的鎖對象，從而定位出死鎖位置,代碼段的絕對地址,偏移量，即在該位置處調(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,列出該進程打開的文件句柄和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,打開的文件,該進程允許打開的最多文件句柄數(shù),建立的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 結(jié)合如下命令可以找到打開了哪個文件 find . type f exec ls i ; print | grep 335047,打開的文件的節(jié)點號，如果文件已經(jīng)被刪除，給文件句柄尚未關(guān)閉，那么pfiles

40、就無法打印出文件名。,Page 37,Proc工具介紹Pflags,報告指定進程的狀態(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,本進程依賴的動態(tài)庫,列舉與指定進程相關(guān)的所有動態(tài)鏈接庫 用法： 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,顯示指定進程地址空間，包括內(nèi)存段

43、大小和訪問權(quán)限設(shè)置 用法：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 共享內(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 計算后臺進程使用的內(nèi)存資源: 337360K - 266240K = 71,120k 這就是一個進程所消耗的內(nèi)存.,Page 41,Proc工具介紹ptree,顯示指定進程相關(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等進程,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,統(tǒng)計進程的執(zhí)行時間 用法：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è)置針對每個進程的限制 用法： 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,文件句柄的個數(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ā)送一個用戶可定義的信號到一個或多個

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