最近我最疼愛的小貓Puji 因為膀胱結石開刀的時候過世了,心情很差請原諒我的口氣沒有很好,也沒有心情寫部落格。
=======================正文=======================
這個題目很多人叫我寫,可是這題目好大,這分明就是整死我咩~
所以我會分幾段慢慢寫。
- JBoss 的 Subsystem
- Datasource
- Web
- Web Service
- EJB
- Hibernate
- JMS
- JCA
- JVM 調校
- OS (作業系統)
先來看一下 DataSource Subsystem, DataSource 的部分主要是針對Connection Pool 做調校。
通常,程式都會需要跟資料庫界接,電腦在本機,尤其是在記憶體的運算很快,但是一旦要外部的資源連接,就是會非常的耗資源。所以現在的應用程式伺服器都會有個Pool 放一些先連接好的 資料庫connection,當程式有需要的時候就可以馬上提供,而不用花那些多餘的資源去連接資料庫。
這就是為什麼要針對Connection Pool 去做調校。
以下會討論到的參數,都是跟效能比較有關係,Datasource 還有很多參數,像是檢核connection 是否正確的,我都不會提到。如果你追求的是非常快速的效能,那我建議你一個檢核都不要加。當然,這樣就會為伺服器上面執行的程式帶來風險。這就是你要在效能與正確,安全性上面的取捨了。 (套句我朋友說的話,不可能又要馬兒好,又要馬兒不吃草的..)
最重要的調校參數就是 Connection 的 Pool 數量。(也就是那個Pool 裡面要放幾條的connection.) 這個參數是每一個應用程式都不一樣的。
min-pool-size
Connection Pool 最少會存留的connection 數量
max-pool-size
Connection Pool 最多可以開啓的 connection 數量
prefill
事先將connection pool 裡面建立好min-pool-size 的connection.
我的建議是觀察一下平常程式要用到的量設定為 min-pool-size 。
加上可能會衝高的最大量以及確認測試過資料庫可以承受的數量 max-pool-size 再 x 20%~30 %以上。不用擔心設的太大,反正你沒用到那麼多,connection pool 也不會真的建這麼多。
還有一個prefill 的參數,我建議是把它打開,這個參數會在JBoss EAP 一起動的時候,把connection pool 裡面的connection 先建立到connection pool 裡面。 這樣就可以減少一開始程式要連接到資料庫要消耗的時間以及資源。
還有一個比較重要的參數,就是 timeout 的參數。
blocking-timeout-millis
這個參數是指,當你的connection pool 裡面所有的connection 都被現在跑的程式拿光光的時候,下一個程式在那裡排隊等待下一個可用connection 的時間。 超過時間就會出exception 了。(PS, 這只是等待拿到connection的時間喔~如果你很快就拿到一個connection, 可是建立的時候可能因為資料庫出問題,所以等了很久,這段的時間是不算的喔。) 預設的時間是 30秒。
idle-timeout-minutes
Connection Pool 裡面的connection 發呆很久沒人用的等待時間,如果超過這個時間 (分鐘計算喔) 都沒人來用它的話~ 那就把這個connection 關掉。 它的底層就是一個叫做 idleRemover 的thread, 大概隔一段時間就會起來scan 看看 connection time 超過idle-timeout的,如果有就關閉。所以connection 並不是一到時間就會馬上自動關閉,要等到 idleRemover scan 時才會真的關掉。 而 idleRemover 大概就是你所有 pool 的設定最小的 idle-timeout-minutes 一半的時間。
set-tx-query-timeout
是否要設定查詢的timeout 時間,當然還是以整個交易timeout 為主。 如果你的query timeout 時間還沒到, 整個transaction(交易) 就 timeout 的話,還是以transaction(交易)第一優先。
query-timeout
這個參數需要上一個 set-tx-query-timeout 設定成true 才會有作用,不然default 就是0 不會timeout. 這個參數是查詢一次要多久的時間,超過的timeout.
如果你不想要太多卡在伺服器上面的交易的話,請盡量把上面的timeout時間設短,當然,相對的程式就會出現很多timeout 的exception, 以正常來說,timeout 的時間不可過長,交易一定要比timeout使用的時間更短,如果很長的話,可能要看一下資料庫的狀態,程式寫的方式,甚至是資源根本就是不夠用。
設定的地方就在 datasource的這個subsystem下,
jdbc:mysql://localhost:5432/MyDB mysql 10 30 true 30000 5 true 30
至於可以觀察哪些數據呢,打開CLI 來看看:
[standalone@localhost:9999 statistics=pool] :read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"ActiveCount" => "0",
"AvailableCount" => "20",
"AverageBlockingTime" => "0",
"AverageCreationTime" => "0",
"CreatedCount" => "0",
"DestroyedCount" => "0",
"InUseCount" => "0",
"MaxCreationTime" => "0",
"MaxUsedCount" => "0",
"MaxWaitCount" => "0",
"MaxWaitTime" => "0",
"TimedOut" => "0",
"TotalBlockingTime" => "0",
"TotalCreationTime" => "0"
}
}
主要看一下 ActiveCount, 看看目前總共有多少活著的connection, AvailableCount 看一下pool裡面是都滿了,還是Connection 大部份都借出去了. MaxUseCount 可以拿來看系統最大最巔峰的時候,開了多少的connection 出去用。 MaxCreationTime 告訴你,建立一個connection 最久花多久。如果很久的話,要查查看資料庫的資源是否夠,或是網路有問題。 如果MaxWaitCount 太高的話,可能是connection pool 太小,或是有connection leak造成要一個connection排隊排太長了等等...
或是你可以在 Console 上面看l,雖然沒有很多參數,但最主要的pool size是可以看見的。
當然,校能調校還是要觀察久一點的比較好,所以這時候拿JON來看一整個禮拜的connection pool 的設定是最棒的拉~。在CLI 上面的參數也大多都看得到。
View comments