一次oracle效能調優的實戰

項目情況：是一個大型公司的內部辦公系統，該系統有兩個和一般公司專屬應用程式不太一樣的特點：一是使用者量非常多，人員數達到2W左右，另一個是採用分級管理的形式，各個分公司資料分開管理。

我們的定位：我們是作為業務平台的供應商參與這個項目的，我們提供底層的開發平台，系統整合商在此基礎上進行二次開發。

在項目從開發到部署的過程中遇到了很多的問題，也反映出很多問題。

一、怎麼回事，跑得比貓還慢

項目開發完畢後部署在Ibm aix 小型機上，32G記憶體，16個cpu。應用伺服器採用的是weblogic9.2，資料庫是oracle10.0.2。上線後發現系統啟動並執行非常緩慢，甚至比開發環境下的tomcat還要慢。於是開始排查原因，最開始是對SQL進行監控，優先考慮是資料庫訪問效能產生瓶頸。通過監控，發現很多業務需要執行大量的SQL語句，查看客戶編寫的相關代碼，發現在查詢資料時迴圈執行了大量SQL。主要原因在於他們在代碼中迴圈調用了我們相關API，一個最典型的例子是通過使用者ID尋找使用者NAME，他們在業務表格裡沒有儲存使用者name，而是在查詢的時候通過使用者ID尋找使用者name填充到頁面，幾乎每一個查詢都是n+1。

另外由於平台使用了hibernate，使得oo編程得非常爽快，導致開發人員完全忽略了相應的資料庫操作所帶來的壓力。很多商務邏輯直接通過PO疊加完成，把一些可以通過很少SQL完成的邏輯全部分散放置到PO裡，導致了大量PO的互動和SQL語句。

開始最佳化SQL，最佳化的同時增加大量業務緩衝。但最佳化完畢後運行緩慢的現象依舊存在，效能有了一定的提升但是不是非常明顯。繼續最佳化，其中考慮過多頻繁訪問的資料使用記憶體資料庫的方式。但是最佳化過後在tomcat上效果明顯，部署到生產環境就問題依舊。於是考慮weblogic的配置問題，作為開發平台供應商，我們只是提供系統開發相關方面的支援，對於應用伺服器和資料庫伺服器只是做基本的配置系統可運行即可。但是在這個問題上系統整合商咬定是我們平台的問題不放，並且存在一個很嚴重的問題：他們使用的是盜版的weblogic，這樣根本就沒有相應的支援人員。

問題的解決：最後是找了一個BEA曾經的開發人員，問題實際非常的簡單，現場部署的weblogic預設是運行在32位機器上，與64位機器存在一定的不相容。通過替換相應的jar包，問題得到瞭解決，主要是IO方面。替換完畢後，速度提升了進30% 。該開發人員說，如果沒有lisence，根本就不會得到這些替換的jar包。

二、記憶體耗盡了

訪問速度的問題解決了，系統的使用量很快上來，馬上遇到新的問題：記憶體耗盡了。嚴重到幾乎每天都要out of memory一次。這種問題在客戶現場頻繁出現。

本地測試，tomcat，sun jdk 通過Jprofiler監測記憶體使用量情況。在並發訪問門戶的情況下，記憶體確實存在暴漲的情況，100並發，記憶體使用量立刻上升了150m左右，繼續並發 100，再增長150m。但是很快在抵達高峰時會有一次gc發生，記憶體使用量穩定在200m，記憶體裡大量char[]數組對象。疲勞測試，記憶體使用量曲線並沒有出現逐漸上升泄露的情況。換weblogic和jrocket測試，gc發生的更加頻繁，記憶體使用量穩定。