Tomcat6優化彙總

前言：

上個星期對平台開發系統進行了首次壓測，在晶晶的壓力測試幫助下，終于将IBM R61的本本跑出了2100使用者的好成績（Tomcat6+Oracle11g+PlatForm+Ubuntu8.10）！

另，不過細節過程可能忘記了，晶晶表介意，大概吧事實講述清楚，好不！！：）

楔子：

壓力測試，通過對tomcat6的逐漸優化，終于讓IBM R61壓測使用者跑上了2100人，有點極限的樣子，單在整個測試過程中除了系統cpu資源使用100%之外，硬碟響應幾乎為無，測試完成後整個系統保持穩定，無崩潰迹象，這說明本本局限了線上壓力的繼續提高（畢竟不是伺服器），呵呵，好了，不介紹了，開始講述，故事正在開始……

第一章 三百已是才能盡，五百哪敢去高攀

初始開始壓力測試時，定的目标為3000戶線上并發的目标（雖然最後也沒有成，但還是比較欣慰的，畢竟是用本本，不是在主業Web伺服器上測試）, 作為适應性的第一測試，隻将使用者壓力定在了500。當晶晶同學将壓力并發測試系統準備好，并完成第一輪測試時，都絕望了–通過使用者數僅僅為280人左右，晶晶同學告訴我“估計你的本本300使用者已經是極限了”。于是，在他的要求下從200開始測試，我無奈的同意了……^>^|||

第二次兩百使用者的測試非常順利的通過，各環節耗時除登入耗時占用比例交大外，其餘各階段都非常合格。測試過程中，系統cpu資源隻提升了5%不到，硬碟無消耗，本本上的各項操作也非常正常，無任何延時現象，資料庫連結監控發現最大連結數沒有突破10。這，這……，這就有點不正常了,壓測過程系統過于平靜、清閑了點。開始和“王老五”分析資料庫原因，突然一拍腦袋，這正是“機關算盡太聰明、反害了卿卿（R61）性命……”

第二章 王老五随語驚夢人，魚财主死摳算線程

“老五呀，資料庫線程怎麼一點點壓力都沒有，R61也是，整個壓測跟玩似的清閑，這很不對勁”，我沮喪的對着王老五說着。王老五撇了我一眼，有轉頭緊盯着oracle資源監控系統，然後就是點頭和“是呀”的回答。我是有點抓狂了，也跑到王老五的筆記本前看着那些代表資料資源的綠條條，心裡就納悶了，怎麼就不紅呢，紅了就好了……。正在我想的時候，王老五随口來了句“連結數相當少，線程壓力幾乎沒有嘛”。驚，絕對的驚，出了一腦門子的汗，……

“對，線程，……，嗯，這和哪裡關聯着呢，到底這扇門通向哪裡？？”我不停的想着，考慮着，眼前已經出現了門，我正在不停的拽那個把手，那個門後面應該就是“我所需要的……”

對了，Ajax Web 通路時線程通路頻繁，tomcat執行線程為單線程響應方式，資料連結數極低（不到10），說明線程池使用效率也同樣低，過多使用者多處于等待執行線程的狀态，這也剛好驗證了晶晶的測試失敗原因–連結逾時。那到底是什麼導緻tomcat線程池使用能力不足呢？這時，我突然想到，Ubuntu系統是一個基于 Linux的系統，一般的系統使用者都是被強制受限的，比如，單線程打開檔案最大數、使用者最大線程數、打開檔案最大尺寸、最大記憶體使用限制……等等。可是普通Ubuntu使用者組使用者是不允許使用調整指令“ulimit”；而且Ubuntu的root使用者是被鎖死的；sudo指令執行，結果是shell中沒有 “ulimit”指令(sudo: ulimit: command not found)。

這正是“門前已掃五升雪，瓦上還聚三升霜……”

第三章 魚頭大海撈蝦米，布圖怯怯啟Root

1、建立root使用者：

sudo passwd root

注：根據提示設定root使用者密碼（建立root使用者）

2、允許root使用者登入

點選 System （系統）-> Preferences（系統管理） -> Login Window（登陸視窗） 菜單，并切換到 Security（安全）選項頁，然後選中其下的“Allow local system administrator login”（允許本地系統管理者登陸）選項。

3、禁用Root使用者

sudo passwd -l root

------------------------------------

另類改變方法：

1.設定好root密碼！

$ sudo passwd root

2. 屏蔽gdm改用終端登入

$ sudo mv /etc/rc2.d/S13gdm /etc/rc2.d/s13gdm

3. 重新開機計算機

4. 以root登入并startx可以了！系統怎樣改都行了，小心哦！！

5. 恢複gdm方式（如果你的gdm可以正常工作的話）

$ sudo mv /etc/rc2.d/s13gdm /etc/rc2.d/S13gdm

6. 重新開機計算機！！

這正是“書到用時方恨少，事非經過不知難……”

第四章 調教TOM晶晶叫好，布圖吃飽硬碟不保

1、開啟Root使用者後，使用root使用者登入，調整Linux系統限制，如下：

ulimit -n 65533

ulimit -u unlimited

進入tomcat目錄，啟動：

./catalina.sh run

看着終端的螢幕開是刷，顯示出清晰的tomcat6的啟動日志

晶晶的壓力測試直接500，在未做其餘任何調整的情況下通過，其中表單送出過程耗是在12秒左右，稍微慢了點，王老五反應資料庫連結數突破到19後停滞，那麼繼續優化

2、調整platform資料源的線程設定

假設釋出目錄為Webroot，那麼在WebRoot/META-INF/下建立context.xml檔案，調整資料源配置

(注：tomcat6才能支援釋出目錄資料源配置，以前的版本改檔案路徑在tomcat安裝路徑下的conf目錄中)

context.xml檔案内容如下：

<?xml version=”1.0″ encoding=”UTF-8″?>

<Context path= “/WebRoot ” privileged= “true” reloadable=”false”>

<Resource name=”sysDataSource” auth=”Container”

type=”javax.sql.DataSource” maxActive=”5000″ maxIdle=”300″ maxWait=”60000″

logAbandoned=”true” username=”yfjz” password=”password”

driverClassName=”oracle.jdbc.driver.OracleDriver”

url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />

<Resource name=”yfjzDataSource” auth=”Container”

type=”javax.sql.DataSource” maxActive=”4000″ maxIdle=”200″ maxWait=”60000″

logAbandoned=”true” username=”yfjz” password=”password”

driverClassName=”oracle.jdbc.driver.OracleDriver”

url=”jdbc:oracle:thin:@10.10.10.XX:1521:al32″ />

</Context>

（注：再次測試300戶時，資料連結監控發現線程上到199，線程已經解禁了）

3、調增tomcat6響應池：

查找tomcat6安裝目錄下conf目錄中的server.xml檔案，進行編輯

屏蔽tomcat預設Connector：

<!–

<Connector port=”8080″ protocol=”HTTP/1.1″

connectionTimeout=”20000″

redirectPort=”8443″ />

–>

建立高線程的Connector：

<Connector port=”8080″ redirectPort=”8443″

maxHttpHeaderSize=”8192″ useBodyEncodingForURI=”true”

minProcessors=”100″ maxProcessors=”5000″

maxThreads=”5000″ minSpareThreads=”1000″ maxSpareThreads=”4000″

enableLookups=”false” acceptCount=”3500″

compression=”on” compressionMinSize=”2048″

compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain”

connectionTimeout=”60000″ disableUploadTimeout=”true” debug=”0″ URIEncoding=”UTF-8″/>

（注：加入響應線程數控制，加入壓縮傳遞模式，調整逾時設定，屏蔽調試模式）

4、增加tomcat6啟動記憶體：

查找tomcat6安裝目錄下bin目錄中catalina.sh檔案，在開始增加如下：

JAVA_OPTS=” -Xms1400m -Xmx1400m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true ”

5、增加oracle響應線程數：

王老五将oracle資料線程響應定為1000,這是測試用的，同時監控oracle連結資源

(想知道這個怎麼設定的，認識王老五的就找他聊聊，不認識的就網上找找吧，呵呵)

6、開始壓測1000戶

晶晶開始測試後，确發現有十來戶一直處于等待狀态，R61本本cpu資源從96%降到10%以下，硬碟燈狂閃，Desktop系統操作響應減緩

使用硬碟資源檢查指令發現，硬碟使用資源為100%，說明硬碟滿了，系統在尋找緩存操作，硬碟和記憶體瘋狂互動

這真是“一波剛平一波起，平湖落石浪千層……”

第五章 查硬碟日志累計，斬輸出平台生春

通過查找，系統硬碟資源撐爆的原因是tomcat日志和platform日志無限追加的原因，解決辦法如下：

1、調整platform日志log4j.properties

将首行的“log4j.rootLogger = DEBUG, A1, A2”改為“log4j.rootLogger = INFO, A1”

（注：很簡單吧：-）

2、調整tomcat6的日志輸出

将下面内容注釋掉：

handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler, 5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

（注：行首加#号就行）

3、晶晶繼續壓測，結果定在2100多戶左右

尾聲：

從整個過程來看，PlatForm在抗壓性上表現突出，自始至終未出現崩盤情況，所有失敗使用者的錯誤提示都為“time-out”，隻是登入響應時間占總流程比重稍高，仍續繼續調整；該測試可以說改變了我對tomcat的定義，在各項優化做足的情況下，tomcat抗亞能力優秀，也從未崩盤，隻是單線程響應是一直诟病的，反映在當叢集使用者出現是表單響應時間便長，緻使我不得不增大了逾時時間（原來定在20秒，後來調整到1分鐘）；系統容載量是一個綜合性的過程，在整個壓測環節中每一步都十分重要，不能僅僅依靠某一個環節的優化就可以安了，在2100戶時，資料庫連結超過800線，系統cpu使用量高達96%，硬碟資源幾乎不耗費，這說明2G的記憶體在處理足夠多的事物。

以上是IBM R61 2G記憶體本壓測從200使用者到2100使用者通過的過程，請需要的人借鑒，也希望多提寶貴意見。

（注：Tomcat6 Connector配置參考了javaeye的配置；部分人物表現有虛構情節，望涉及人員一笑了事）