jee性能問題-免費(fèi)閱讀
【正文】 如果主要是程序的代碼導(dǎo)致的惡果那你應(yīng)該帶著問題去尋求負(fù)責(zé)代碼的人尋求幫助，但是如果問題是由環(huán)境引起的，那么就要依靠你的操作來解決了。超時回滾就是當(dāng)程序服務(wù)器中的程序處理請求時超時。事務(wù)會以下面2中方式結(jié)束: 1. 事務(wù)提交 2. 事務(wù)回滾 當(dāng)一個事務(wù)被提交的時候，說明它已經(jīng)完全成功了，但是當(dāng)它回滾的時候，就說明發(fā)生了一些錯誤。池能夠讓程序共享資源，但是會讓你的程序付出潛在的等待時間。但一般來說，我們更需要關(guān)心緩存的miss ratio。當(dāng)你離開超市的時候，你需要帶上你的孩子，不是其他人的孩子，而是你自己的。這段被浪費(fèi)的時間本來是為了讓它去裝載后面的調(diào)用的?！ ∫粋€程序服務(wù)器如果設(shè)置連接的數(shù)量不合理就會有下面這些特征: (潛在的) (因為沒有足夠的請求能夠讓他繁忙起來) JDBC prepared statements 和JDBC相關(guān)的另一個重要的設(shè)置就是:為JDBC使用的statement 所預(yù)設(shè)的緩存的大小。事實(shí)上，很多的大城市都有這樣功能，但根本沒用，他們真正需要的是一些更多的小路(CPU)，涌向高速公路的速度真的降低了，那么交通會變的正常起來。有些時候，垃圾收集也可能導(dǎo)致CPU使用率很高，但是垃圾收集導(dǎo)致的CPU使用率很高和池過大導(dǎo)致的使用率有一個主要的區(qū)別就是:垃圾收集引起的只是短時間的高使用率就象個釘子，而池過大導(dǎo)致的就是一直持續(xù)很高呈線性。但為第二個程序配置的池是100，就有點(diǎn)太大了，因為CPU可能就能應(yīng)付50個線程。這個時候，我會按一定幅度增加調(diào)節(jié)池的大小，并在未處理請求的數(shù)量減少前一直監(jiān)視程序的吞吐量，你需要一個合理甚至更好的負(fù)載量者，一個精確的負(fù)載量測試工具可以準(zhǔn)確的幫你測試出結(jié)果。線程池的大小就是程序可以同時處理的請求的數(shù)量。于是就導(dǎo)致了內(nèi)存溢出錯誤，我把他的持久空間改為512M大小，并去掉了 noclassgc 參數(shù)。JVM提供了一個參數(shù)讓你不的程序不卸載已經(jīng)裝載到持久空間中的類文件: –noclassgc 這個參數(shù)選項告訴JVM不要跑到持久空間去執(zhí)行垃圾收集釋放其中已經(jīng)裝載的類文件。如果商業(yè)規(guī)則允許的話最好能縮短會話超時的時間，以減少堆占用空間的沖突。同樣，在SESSION中存放對象的時候，當(dāng)程序明確說明此SESSION失效的或者會話執(zhí)行超時的時候，這些對象才會自動被釋放。這些靜態(tài)對象是造成內(nèi)存泄漏的主要原因。超過這個會話的最長時間就是會話超時，他們在程序服務(wù)器中設(shè)置。WEB服務(wù)器會向應(yīng)用程序服務(wù)器傳送一系列參數(shù)和屬性，也就是在SERVLET和JSP之間傳輸HttpServletRequest中的對象。 我將這些情況稱為假泄漏，表現(xiàn)在下面幾種情況: 1. 分析過早 2. Session泄漏 3. 異常的持久區(qū)域 這章節(jié)對這些假泄漏都進(jìn)行了調(diào)查，描述了如何去判斷這些情況以及如何處理. 不要過早分析 為了在尋找內(nèi)存泄漏的時候盡量減少出現(xiàn)判斷錯誤的可能性，你應(yīng)當(dāng)在適當(dāng)?shù)臅r候分析堆。這個方法不一定總有用，但如果是因為請求引起的對象泄漏的話，就會有很大的幫助。因此你可能猜測到了，如果想尋找可能發(fā)生的內(nèi)存泄漏應(yīng)該觀察堆中所有的動作，堆的使用率是在提高? 如何分析內(nèi)存泄漏 內(nèi)存泄漏非常難確定，如果你能夠確定是請求導(dǎo)致的，那你的工作就非常簡單了。和所有的跟蹤技術(shù)一樣，日值記錄詳細(xì)的程度影響著JVM的性能，你想得到的信息越詳細(xì)，付出的代價也就越高。當(dāng)JAVA中的一個對象包含了一個并不想要的一個指向其他對象的引用的時候，內(nèi)存就會泄漏，這個引用阻止了垃圾收集器去回收它所占據(jù)的內(nèi)存?！ D2和圖3展示的是了小幅度收集如何運(yùn)行圖2?！ 榱藢ふ疫@個問題的真正根源，你需要判斷是內(nèi)存泄漏還是以O(shè)utOfMemoryError形式出現(xiàn)的其他一些故障。 Outofmemory錯誤一般是JAVA內(nèi)存泄漏引起的。 眾多解決問題的方法思路基本相同，第一天我同要解決問題的客戶接觸，接觸的時候，我會尋找已經(jīng)出現(xiàn)的問題以及造成的負(fù)面的影響。作為一個JAVAEE問題解決專家，我曾經(jīng)面對過眾多的環(huán)境同時也寫了不少常見問題的觀察報告。 引發(fā)outofmemory 錯誤的原因 在你打算解決outofmemory 錯誤之前，首先了解為什么會引發(fā)這個錯誤對你有很大的幫助。而且，大多數(shù)這些泄漏的對象并不是象DOUBLE或者INTEGER這樣的簡單對象，而可能是存在于堆中一系列相關(guān)的對象。如果填充到第二個生存者空間中的有效對象被第一個生存者空間或EDEN中的對象引用，那么這些對象就是長期存在的(也就是說，他們被拷貝到老一代)?！ ∫陨暇褪荢UN實(shí)現(xiàn)的垃圾收集器機(jī)制，你可以看出在老一代中的對象會被大幅度調(diào)整器收集清除。如果內(nèi)存泄漏的確存在，這些造成泄漏的對象就會不斷的占據(jù)空間，直至造成內(nèi)存溢出。IBM JVM內(nèi)存管理模式 IBM的JVM的機(jī)制有一點(diǎn)不同?！ ∵@個時候，你需要去和開發(fā)者交流，告訴他你所碰到的棘手的請求，他們可以判斷究竟是對象泄漏還是為了某個目的特地讓對象保留下來的。這個報告并不能告訴你造成泄漏的是代碼還是某個對象，而是告訴你在內(nèi)存模擬器中應(yīng)該留意那些類型的請求。如果是上升，這個時候就需要分析內(nèi)存中的SESSION了。屬性和參數(shù)被放在各自用戶的HttpSession對象中，并通過它讓程序的SERVLET和JSP交流。 如果數(shù)據(jù)不是存儲這個四個地方(頁面范圍，請求范圍，會話范圍，程序范圍)那就可能存儲在下面的對象中: 1. 靜態(tài)變量 2. 長生命周期的類變量 每個類的靜態(tài)變量被JVM(JAVA虛擬機(jī))所控制，他們存在與否和類是否已經(jīng)被初始化無關(guān)。在他們自己內(nèi)部本身存貯這些緩存配置是個不錯的選擇，但存貯在SERVLET中是最糟糕的情況。 通常來說，如果你執(zhí)行了一個很大的會話，你應(yīng)該盡量去減少它所占用的內(nèi)存空間，如果可以的話最好能重構(gòu)程序，以減少session所占據(jù)的內(nèi)存空間。JVM利用程序的內(nèi)存來裝載字節(jié)流文件，這個內(nèi)存空間稱為持久空間。在我調(diào)查了詳細(xì)的關(guān)于堆和程序內(nèi)存利用的收集器的記錄后，我迅速發(fā)覺堆的狀態(tài)非常正常，但程序確發(fā)生了內(nèi)存溢出。把持久空間設(shè)置成512M大小就象給一個腳痛的人吃止痛藥，雖然暫時緩解了痛，但是腳還是沒有好，依然需要醫(yī)生把痛治療好，否則只是把問題延遲了而已。Figure 8. 服務(wù)器處理請求的次序結(jié)構(gòu)線程池太小 每當(dāng)我碰到有人抱怨裝載速度的性能隨著裝載的數(shù)量的增加變的越來越糟糕的時候，我會首先檢查線程池。第一個程序?qū)φ埱蟮幕貞?yīng)會很塊，且不怎么占據(jù)CPU?！ 【€程池太大 除了線程池數(shù)量太小之外的情況外，環(huán)境也可能把線程數(shù)量配置的過大。在
法律信息相關(guān)推薦
鄂ICP備17016276號-1