Oracle應用伺服器效能監控與調優（CPU負載高）
我剛被一家公司錄用，我的老闆給我一個績效問題，要我盡快解決。我之前在伺服器端沒有任何 Java EE 經驗。
讓我開始了解該系統，但仍然找不到解決方案：
我們有一個 Oracle 應用伺服器 (10.1.）和 Oracle 資料庫伺服器（9.2.），軟體人員專門使用 JSF 1.2 和 Ajax 編寫了一種大型 J2EE 專案（X 專案），該專案僅在該專案中使用。他們在程式碼中積極使用 PL/SQL。
於是，我們啟動了應用程式伺服器（Solaris機器），一切看起來都OK了。用戶從週一開始從不同位置開始使用該應用程式（應用程式 200 有用戶帳戶，我剛剛檢查並看到連接池設定正確，會話僅活動 15 分鐘）。
一段時間後（2天）CPU利用率變高，%60，晚上還是一樣沒有任何變化（此時線上用戶量接近1、2），甚至它開始使用分配給同一台伺服器上其他應用程式的 CPU，因為它們釋放了 如果我們不重新啟動伺服器，兩天後利用率就會變成 90％，應用程式非常慢，以至於最終用戶開始呼叫。
主要問題是軟體工程師說程式碼很清晰，系統和DBA經理說我們有正確的配置，其他應用程式似乎沒問題，為什麼這個問題只發生在X應用程式上。
我開始將資料庫複製到測試平台並將其升級到最新版本，如果存在錯誤或不存在錯誤，也對應用程式伺服器（Weblogic）執行相同的操作。我只自己測試了一個用戶和 weblogic 管理面板，我可以追蹤線程並轉儲它們。我注意到有一些線程顯示為霸佔。當我檢查手冊並控制追蹤時，我發現它指示我從 .java 檔案呼叫 PL/SQL 程式碼的行號。該軟體工程。說是的，我們有非常複雜的 PL/SQL 程式碼，但是與應用程式伺服器有什麼關係？這是資料庫伺服器的問題，我想他們是對的......
我知道這個問題有很多漏洞，我想提供更多詳細信息，但我很欣賞您指導我的方式。
提前致謝 ...
編輯：伺服器的 CPU 和記憶體足以運行更複雜的應用程式
答案1
大量 PL/SQL 呼叫會阻塞執行緒 - 因此 CPU 使用率會下降。
對於緩慢的應用程式伺服器，我的第一個呼叫是檢查 gc 日誌 - 查找頻繁的主要收集（這表明記憶體洩漏或 JVM 只是需要更多記憶體）。
我負責的系統變成了很多從厚重的 Oracle 驅動程式切換到輕量級 jdbc 驅動程式後更加穩定 - 儘管問題主要表現為容器崩潰。
日誌應該能夠很好地指示系統上的任何問題 - 但很大程度上取決於開發人員選擇在其中寫入的內容。緩慢的 SQL 可能會導致連接池耗盡 - 確保池正在記錄連接統計資料。也要確保 JVM 的 ulimit 設定正確。
由於您在資料庫層執行 9i，因此您不會擁有 AWR 功能 - 您必須執行 statspack（但這應該已經成為網站效能管理的標準做法）來確定導致資料庫出現問題的原因。
效能的逐漸下降表示應用程式中存在記憶體洩漏 - 通常這是由於物件未取消引用並因此符合垃圾回收條件而引起的 - 即程式設計問題。這在大多數 Java 分析工具中應該是顯而易見的。
我注意到有一些線程顯示為佔用
除非您使用實際工作負載進行測試，否則結果幾乎毫無用處。