一次Linux、Tomcat和Oracle數據庫優化過程

因受公司保密協定，相關係統、中間件名稱由系統A、系統B、TomcatA、TomcatB、ORACLE-一、ORACLE-2所代替。涉及到的地區、實際業務均爲代號，請知曉

• 系統A的初始需求：

系統A的使用用戶，在系統A上進行導出功能的時候，常常會引起系統A宕機，通過簡單評估，斷定系統硬件不足，須要擴容並遷移到雲端用X86機器替代原有小型機。

接到這個case的時候，我先登上服務器上看了一下，是一臺windows server 2003服務器。
裏面跑了一個Tomcat應用程序，就是這個應用程序常常內存溢出。

看了一下服務器的位數，爲64位，該服務器物理內存爲16G，實際使用6.87G，剩餘將近10g空閒物理內存未使用，查詢系統註冊表，發現Tomcat實際啓動內存爲1G，明顯不正常。。
因而向用戶申請重啓，嘗試增長Tomcat實際啓動內存的操做。

實際操做後添加內存失敗，緣由爲目前部署的tomcat版本爲32位，只能識別1g內存，超過1g內存在java虛擬機內就會報錯。配置高內存後，沒法啓動tomcat服務。

下圖爲用命令添加內存數測試java虛擬機是否能夠正常運行，能夠看到2048m的時候是報錯的。

實際用DOS下查看tomcat的版本信息：爲x86 32位版本。

看到這裏我就有點崩潰了。。64位的機器，用32位的中間件，內存不溢出都有鬼。。。

• 系統A的上雲之路

系統A的上雲之路能夠說是一波三折，中間經歷各類各樣的問題，歷時近小1個半月，終於遷移成功了。本覺得這下終於能夠牛B了，結果噩夢剛剛開始。

地區A用戶用系統A，是爲了監控他們想要的業務的，但當實際業務發生時，系統A超過了它的承載能力，而且當時上雲的時候，x86機器硬件評估也沒作好（不過過後想一想，也多虧了這塊，獲得了優化這個系統，否則問題一直就被高配置給掩蓋了。）

具體問題場景

受實際業務影響，系統A與系統B之間的交互超過了系統A的最大承載能力，系統A先出問題，而後致使系統B跟隨出問題，兩個系統瞬間宕機。

看這個Case的時候，歷時好久，也經歷了好幾個步驟才從一團雜亂無章的現象中縷清頭緒，整理以下：

系統A報錯：

java.sql.SQLException: Couldn't perform the operation setAutoCommit: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs).

當時上網查詢了一些相關文檔，找到一篇：

參考文檔：http://www.cnblogs.com/javawe...

文檔中明確指出：

simultaneousBuildThrottle參數設置太小會引起這個問題

知道問題點在這了，因而調整了一下應用程序內的配置文件：
調整simultaneousBuildThrottle參數爲1000，增大數據池併發處理量。

• 系統A與系統B之間的無情糾紛

調整好了上個case不到半個月，又接到新case，用戶反映系統A很是卡，幾乎不能用。
剛開始我還有點不相信，結果本身上去操做了一下，點一下操做要等5分鐘左右，而且以前說過了，系統A有問題會連帶系統B也跟着有問題，這樣兩個系統的維護負責人的矛盾就開始慢慢激發了。。

研發也在跟進這方面的問題，而且作了至關一部分工做，把TOMCAT層面的鏈接池、Session數獲得了控制，至少發生卡慢問題的時候，不會回收不了了，只是效率的問題。

到這裏開始想到了以前系統A上雲的時候，數據庫服務器ORACLE-1的系統idle%值很低，當時斷定爲x86的性能不夠，還特地申請了高配服務器。

可是做爲一名技術人員，對系統A的瞭解來看，如今的配置給系統A用也應該綽綽有餘。
因而開始着手查看AWR報告，分析TOP SQL

分析了一夜，真發現了3個會致使CPU處理異常高的SQL語句。
單獨執行它們，一個都在1秒鐘左右，看似不會對CPU形成影響，可是關聯到業務，可能就不行了，這些SQL執行的頻率至關之高，千里之堤潰於蟻穴，看來這些SQL的優化勢在必行。

繼續分析SQL語句，它們的共性是，查詢的時候都用了like關鍵字。
再查看對應的表結構，發現like查詢的字段正好是索引列。
再看一眼like裏寫的東西，到數據庫表裏一看，like裏寫的東西自己就可以肯定惟一性。。不知道爲何用like。。。誰能告訴我，怎麼想的？？對於這個實在不能忍受。。

優化這部分，實際沒用多長時間，找研發同事修改了一上午就搞定了。
結果觀察效果，一下數據庫服務器的idle%上升了50%，以前是可憐的0%。

優化到50%，很顯然不是我們的最終目的，最終目的是讓系統A變成正常的系統，cpu佔用率在20%如下。

因而繼續在TOP SQL中找，發現一張表的數據量級已經到了900W，而且沒有索引。

真的好醉。。。who can help me?

900w的表，delete基本是不用想了，問了下相關負責同事，直接執行truncate操做。
執行完畢後，cpu利用率一下跌落到7%！！ 系統IDLE值上升到了95%！！

附一張對比圖，數據從AWR報告中取的。

如今再也沒有用戶說卡慢了，由於idle值上去了，哈哈。

• 後續系統A還有沒有可優化空間

答案是確定有，通過觀察，系統A有好幾個大表，並無分區，這塊確定對查詢有影響。而且幾個業務功能的邏輯也有可優化空間，可是由於上面的優化作完了，這塊就能夠正常排期，沒有那麼緊急了。