項目情況：是一個大型公司的內(nèi)部辦公系統(tǒng)，該系統(tǒng)有兩個和一般企業(yè)應用不太一樣的特點：一是用戶量非常多，人員數(shù)達到2W左右，另一個是采用分級管理的形式，各個分公司數(shù)據(jù)分開管理。

我們的定位：我們是作為業(yè)務(wù)平臺的提供商參與這個項目的，我們提供底層的開發(fā)平臺，系統(tǒng)集成商在此基礎(chǔ)上進行二次開發(fā)。

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

一、怎么回事，跑得比貓還慢
項目開發(fā)完畢后部署在Ibm aix 小型機上，32G內(nèi)存，16個cpu。應用服務(wù)器采用的是weblogic9.2，數(shù)據(jù)庫是oracle10.0.2。上線后發(fā)現(xiàn)系統(tǒng)運行的非常緩慢，甚 至比開發(fā)環(huán)境下的tomcat還要慢。于是開始排查原因，最開始是對SQL進行監(jiān)控，優(yōu)先考慮是數(shù)據(jù)庫訪問性能產(chǎn)生瓶頸。通過監(jiān)控，發(fā)現(xiàn)很多業(yè)務(wù)需要執(zhí)行 大量的SQL語句，查看客戶編寫的相關(guān)代碼，發(fā)現(xiàn)在查詢數(shù)據(jù)時循環(huán)執(zhí)行了大量SQL。主要原因在于他們在代碼中循環(huán)調(diào)用了我們相關(guān)API，一個最典型的例 子是通過用戶ID查找用戶NAME，他們在業(yè)務(wù)表格里沒有保存用戶name，而是在查詢的時候通過用戶ID查找用戶name填充到頁面，幾乎每一個查詢都 是n+1。
 
另外由于平臺使用了hibernate，使得oo編程得非常爽快，導致開發(fā)人員完全忽略了相應的數(shù)據(jù)庫操作所帶來的壓力。很多業(yè)務(wù)邏輯直接通過PO疊加完成，把一些可以通過很少SQL完成的邏輯全部分散放置到PO里，導致了大量PO的交互和SQL語句。

開始優(yōu)化SQL，優(yōu)化的同時增加大量業(yè)務(wù)緩存。但優(yōu)化完畢后運行緩慢的現(xiàn)象依舊存在，性能有了一定的提升但是不是非常明顯。繼續(xù)優(yōu)化，其中考慮過 多頻繁訪問的數(shù)據(jù)使用內(nèi)存數(shù)據(jù)庫的方式。但是優(yōu)化過后在tomcat上效果明顯，部署到生產(chǎn)環(huán)境就問題依舊。于是考慮weblogic的配置問題，作為開 發(fā)平臺提供商，我們只是提供系統(tǒng)開發(fā)相關(guān)方面的支持，對于應用服務(wù)器和數(shù)據(jù)庫服務(wù)器只是做基本的配置系統(tǒng)可運行即可。但是在這個問題上系統(tǒng)集成商咬定是我 們平臺的問題不放，并且存在一個很嚴重的問題：他們使用的是盜版的weblogic，這樣根本就沒有相應的技術(shù)支持。

問題的解決：最后是找了一個BEA曾經(jīng)的開發(fā)人員，問題實際非常的簡單，現(xiàn)場部署的weblogic默認是運行在32位機器上，與64位機器存 在一定的不兼容。通過替換相應的jar包，問題得到了解決，主要是IO方面。替換完畢后，速度提升了進30% 。該開發(fā)人員說，如果沒有l(wèi)isence，根本就不會得到這些替換的jar包。

二、內(nèi)存耗盡了
訪問速度的問題解決了，系統(tǒng)的使用量很快上來，馬上遇到新的問題：內(nèi)存耗盡了。嚴重到幾乎每天都要out of memory一次。這種問題在客戶現(xiàn)場頻繁出現(xiàn)。

本地測試，tomcat，sun jdk 通過Jprofiler監(jiān)測內(nèi)存使用情況。在并發(fā)訪問門戶的情況下，內(nèi)存確實存在暴漲的情況，100并發(fā)，內(nèi)存使用立刻上升了150m左右，繼續(xù)并發(fā) 100，再增長150m。但是很快在抵達高峰時會有一次gc發(fā)生，內(nèi)存使用穩(wěn)定在200m，內(nèi)存里大量char[]數(shù)組對象。疲勞測試，內(nèi)存使用曲線并沒 有出現(xiàn)逐漸上升泄露的情況。換weblogic和jrocket測試，gc發(fā)生的更加頻繁，內(nèi)存使用穩(wěn)定。
 
但是現(xiàn)場依舊頻繁當機，內(nèi)存根本釋放不了，一直逐漸增長，典型的內(nèi)存泄露。對系統(tǒng)緩存、單態(tài)對象包括spring管理的對象、IO流進行了統(tǒng)一 排查，依舊沒有找到內(nèi)存泄露的原因。使用IBM 工具分析heapdump文件，結(jié)果還是大量的char[]數(shù)組對象占據(jù)內(nèi)存，查找應用，找不到相關(guān)業(yè)務(wù)對象引用。
 
問題解決：問題解決是一篇偶爾搜到的oracle論壇的帖子，這里http://forums.oracle.com/forums/message.jspa?messageID=1040570 。原因在于oracle10的數(shù)據(jù)庫驅(qū)動對statement最后執(zhí)行的結(jié)果集有著引用，并且不會釋放，目的在于通過內(nèi)存而換取更好的性能。數(shù)據(jù)庫連接采 用的是weblogic的連接池，關(guān)于connection有個相關(guān)的statement cache設(shè)定，設(shè)定一個connection能夠被緩存的statement個數(shù)，最大是1024，而現(xiàn)場就被設(shè)定為了1024！connection pool的connection個數(shù)被設(shè)置為了500 。真是個恐怖的設(shè)置。在將1024改為10后，內(nèi)存使用量轟然倒地，穩(wěn)定在1g左右。這個設(shè)置是在前面系統(tǒng)訪問速度存在問題時由系統(tǒng)集成商的開發(fā)人員設(shè)置 上去的，他們將所有和優(yōu)化相關(guān)的參數(shù)全部開到了最大。這個問題要是用戶購買的是正版的weblogic和oracle的話，相信也會很快得到解決。

三、線程阻塞
內(nèi)存泄露的問題解決后，線程阻塞的問題浮出水面。系統(tǒng)集成商報告是線程死鎖，通過分析工具其實是線程阻塞，主要問題在于系統(tǒng)用到了 synchronized關(guān)鍵字，對工作流相關(guān)API全部使用了synchronized，原因在這里：http: //ronghao.javaeye.com/blog/205731 。分析發(fā)現(xiàn)一個工作項提交的操作在連接數(shù)據(jù)庫時被掛起了20分鐘！造成了大量線程的排隊阻塞。被掛起的原因有很多種。我們采用的方法是將接口拆分和設(shè)置事 務(wù)timeout時間。但是這顯然不是一個好方法。最后是去掉所有的synchronized關(guān)鍵字，將同步的問題交由數(shù)據(jù)庫解決，問題解決。

四、反思
1、系統(tǒng)集成商為什么不購買正版？
2、開發(fā)平臺提供商究竟在項目開發(fā)中處于一種什么樣的位置？開發(fā)平臺是否對所有軟件開發(fā)問題都要負責？
3、開發(fā)平臺是越封裝越快樂嗎？還是越封裝越丑陋？

更具體的細節(jié)在這里：

 AIX+weblogic性能診斷記錄

http://www.aygfsteel.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）