#
摘要: 借助與spring AOP，spring提供了強大的基于聲明式事務管理方式，它很好對事務管理代碼和具體業務邏輯進行了解藕，使我們在coding過程不要去關心事務管理的邏輯。下面我們借助一個例子來將分析spring內部的實現。1. 例子1.1 datasource配置[html] view plaincopyprint? <bean id="dataS...
閱讀全文
基于合理的數據庫設計，經過深思熟慮后為表建立索引，是獲得高性能數據庫系統的基礎。而未經合理分析便添加索引，則會降低系統的總體性能。索引雖然說提高了數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間。
是否要為表增加索引、索引建立在那些字段上，是創建索引前必須要考慮的問題。解決此問題的一個比較好的方法，就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的字段建立索引。基于優化器對SQL語句的優化處理，我們在創建索引時可以遵循下面的一般性原則：
（1）為經常出現在關鍵字order by、group by、distinct后面的字段，建立索引。
在這些字段上建立索引，可以有效地避免排序操作。如果建立的是復合索引，索引的字段順序要和這些關鍵字后面的字段順序一致，否則索引不會被使用。
（2）在union等集合操作的結果集字段上，建立索引。其建立索引的目的同上。
（3）為經常用作查詢選擇的字段，建立索引。
（4）在經常用作表連接的屬性上，建立索引。
（5）考慮使用索引覆蓋。對數據很少被更新的表，如果用戶經常只查詢其中的幾個字段，可以考慮在這幾個字段上建立索引，從而將表的掃描改變為索引的掃描。
除了以上原則，在創建索引時，我們還應當注意以下的限制：
（1）限制表上的索引數目。
對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。
（2）不要在有大量相同取值的字段上，建立索引。
在這樣的字段（例如：性別）上建立索引，字段作為選擇條件時將返回大量滿足條件的記錄，優化器不會使用該索引作為訪問路徑。
（3）避免在取值朝一個方向增長的字段（例如：日期類型的字段）上，建立索引；對復合索引，避免將這種類型的字段放置在最前面。
由于字段的取值總是朝一個方向增長，新記錄總是存放在索引的最后一個葉頁中，從而不斷地引起該葉頁的訪問競爭、新葉頁的分配、中間分支頁的拆分。此外，如果所建索引是聚集索引，表中數據按照索引的排列順序存放，所有的插入操作都集中在最后一個數據頁上進行，從而引起插入“熱點”。
（4）對復合索引，按照字段在查詢條件中出現的頻度建立索引。
在復合索引中，記錄首先按照第一個字段排序。對于在第一個字段上取值相同的記錄，系統再按照第二個字段的取值排序，以此類推。因此只有復合索引的第一個字段出現在查詢條件中，該索引才可能被使用。
因此將應用頻度高的字段，放置在復合索引的前面，會使系統最大可能地使用此索引，發揮索引的作用。
（5）刪除不再使用，或者很少被使用的索引。
表中的數據被大量更新，或者數據的使用方式被改變后，原有的一些索引可能不再被需要。數據庫管理員應當定期找出這些索引，將它們刪除，從而減少索引對更新操作的影響。
轉自http://www.cnblogs.com/xuhan/archive/2011/07/25/2116156.html
轉自：http://www.aygfsteel.com/cenwenchu/archive/2008/06/30/211712.html
SIP的第四期結束了，因為控制策略的豐富，早先的的壓力測試結果已經無法反映在高并發和高壓力下SIP的運行狀況，因此需要重新作壓力測試。跟在測試人員后面做了快一周的壓力測試，壓力測試的報告也正式出爐，本來也就算是告一段落，但第二天測試人員說要修改報告，由于這次作壓力測試的同學是第一次作，有一個指標沒有注意，因此需要修改幾個測試結果。那個沒有注意的指標就是load average，他和我一樣開始只是注意了CPU，內存的使用狀況，而沒有太注意這個指標，這個指標與他們通常的限制（10左右）有差別。重新測試的結果由于這個指標被要求壓低，最后的報告顯然不如原來的好看。自己也沒有深入過壓力測試，但是覺得不搞明白對將來機器配置和擴容都會有影響，因此去問了DBA和SA，得到的結果相差很大，看來不得不自己去找找問題的根本所在了。
通過下面的幾個部分的了解，可以一步一步的找出Load Average在壓力測試中真正的作用。
CPU時間片
為了提高程序執行效率，大家在很多應用中都采用了多線程模式，這樣可以將原來的序列化執行變為并行執行，任務的分解以及并行執行能夠極大地提高程序的運行效率。但這都是代碼級別的表現，而硬件是如何支持的呢？那就要靠CPU的時間片模式來說明這一切。程序的任何指令的執行往往都會要競爭CPU這個最寶貴的資源，不論你的程序分成了多少個線程去執行不同的任務，他們都必須排隊等待獲取這個資源來計算和處理命令。先看看單CPU的情況。下面兩圖描述了時間片模式和非時間片模式下的線程執行的情況：
圖 1 非時間片線程執行情況
圖 2 非時間片線程執行情況
在圖一中可以看到，任何線程如果都排隊等待CPU資源的獲取，那么所謂的多線程就沒有任何實際意義。圖二中的CPU Manager只是我虛擬的一個角色，由它來分配和管理CPU的使用狀況，此時多線程將會在運行過程中都有機會得到CPU資源，也真正實現了在單CPU的情況下實現多線程并行處理。
多CPU的情況只是單CPU的擴展，當所有的CPU都滿負荷運作的時候，就會對每一個CPU采用時間片的方式來提高效率。
在Linux的內核處理過程中，每一個進程默認會有一個固定的時間片來執行命令（默認為1/100秒），這段時間內進程被分配到CPU，然后獨占使用。如果使用完，同時未到時間片的規定時間，那么就主動放棄CPU的占用，如果到時間片尚未完成工作，那么CPU的使用權也會被收回，進程將會被中斷掛起等待下一個時間片。
CPU利用率和Load Average的區別
壓力測試不僅需要對業務場景的并發用戶等壓力參數作模擬，同時也需要在壓力測試過程中隨時關注機器的性能情況，來確保壓力測試的有效性。當服務器長期處于一種超負荷的情況下運行，所能接收的壓力并不是我們所認為的可接受的壓力。就好比項目經理在給一個人估工作量的時候，每天都讓這個人工作12個小時，那么所制定的項目計劃就不是一個合理的計劃，那個人遲早會垮掉，而影響整體的項目進度。
CPU利用率在過去常常被我們這些外行認為是判斷機器是否已經到了滿負荷的一個標準，看到50%-60%的使用率就認為機器就已經壓到了臨界了。CPU利用率，顧名思義就是對于CPU的使用狀況，這是對一個時間段內CPU使用狀況的統計，通過這個指標可以看出在某一個時間段內CPU被占用的情況，如果被占用時間很高，那么就需要考慮CPU是否已經處于超負荷運作，長期超負荷運作對于機器本身來說是一種損害，因此必須將CPU的利用率控制在一定的比例下，以保證機器的正常運作。
Load Average是CPU的Load，它所包含的信息不是CPU的使用率狀況，而是在一段時間內CPU正在處理以及等待CPU處理的進程數之和的統計信息，也就是CPU使用隊列的長度的統計信息。為什么要統計這個信息，這個信息的對于壓力測試的影響究竟是怎么樣的，那就通過一個類比來解釋CPU利用率和Load Average的區別以及對于壓力測試的指導意義。
我們將CPU就類比為電話亭，每一個進程都是一個需要打電話的人。現在一共有4個電話亭（就好比我們的機器有4核），有10個人需要打電話。現在使用電話的規則是管理員會按照順序給每一個人輪流分配1分鐘的使用電話時間，如果使用者在1分鐘內使用完畢，那么可以立刻將電話使用權返還給管理員，如果到了1分鐘電話使用者還沒有使用完畢，那么需要重新排隊，等待再次分配使用。
圖 3 電話使用場景
上圖中對于使用電話的用戶又作了一次分類，1min的代表這些使用者占用電話時間小于等于1min，2min表示使用者占用電話時間小于等于2min，以此類推。根據電話使用規則，1min的用戶只需要得到一次分配即可完成通話，而其他兩類用戶需要排隊兩次到三次。
電話的利用率 = sum (active use cpu time)/period
每一個分配到電話的使用者使用電話時間的總和去除以統計的時間段。這里需要注意的是是使用電話的時間總和(sum(active use cpu time))，這與占用時間的總和(sum(occupy cpu time))是有區別的。（例如一個用戶得到了一分鐘的使用權，在10秒鐘內打了電話，然后去查詢號碼本花了20秒鐘，再用剩下的30秒打了另一個電話，那么占用了電話1分鐘，實際只是使用了40秒）
電話的Average Load體現的是在某一統計時間段內，所有使用電話的人加上等待電話分配的人一個平均統計。
電話利用率的統計能夠反映的是電話被使用的情況，當電話長期處于被使用而沒有的到足夠的時間休息間歇，那么對于電話硬件來說是一種超負荷的運作，需要調整使用頻度。而電話Average Load卻從另一個角度來展現對于電話使用狀態的描述，Average Load越高說明對于電話資源的競爭越激烈，電話資源比較短缺。對于資源的申請和維護其實也是需要很大的成本，所以在這種高Average Load的情況下電話資源的長期“熱競爭”也是對于硬件的一種損害。
低利用率的情況下是否會有高Load Average的情況產生呢？理解占有時間和使用時間就可以知道，當分配時間片以后，是否使用完全取決于使用者，因此完全可能出現低利用率高Load Average的情況。由此來看，僅僅從CPU的使用率來判斷CPU是否處于一種超負荷的工作狀態還是不夠的，必須結合Load Average來全局的看CPU的使用情況和申請情況。
所以回過頭來再看測試部對于Load Average的要求，在我們機器為8個CPU的情況下，控制在10 Load左右，也就是每一個CPU正在處理一個請求，同時還有2個在等待處理。看了看網上很多人的介紹一般來說Load簡單的計算就是2* CPU個數減去1-2左右（這個只是網上看來的，未必是一個標準）。
補充幾點：
1．對于CPU利用率和CPU Load Average的結果來判斷性能問題。首先低CPU利用率不表明CPU不是瓶頸，競爭CPU的隊列長期保持較長也是CPU超負荷的一種表現。對于應用來說可能會去花時間在I/O,Socket等方面，那么可以考慮是否后這些硬件的速度影響了整體的效率。
這里最好的樣板范例就是我在測試中發現的一個現象：SIP當前在處理過程中，為了提高處理效率，將控制策略以及計數信息都放置在Memcached Cache里面，當我將Memcached Cache配置擴容一倍以后，CPU的利用率以及Load都有所下降，其實也就是在處理任務的過程中，等待Socket的返回對于CPU的競爭也產生了影響。
2．未來多CPU編程的重要性。現在服務器的CPU都是多CPU了，我們的服務器處理能力已經不再按照摩爾定律來發展。就我上面提到的電話亭場景來看，對于三種不同時間需求的用戶來說，采用不同的分配順序，我們可看到的Load Average就會有不同。假設我們統計Load的時間段為2分鐘，如果將電話分配的順序按照：1min的用戶，2min的用戶，3min的用戶來分配，那么我們的Load Average將會最低，采用其他順序將會有不同的結果。所以未來的多CPU編程可以更好的提高CPU的利用率，讓程序跑的更快。
load Average
1.1：什么是Load？什么是Load Average?
Load 就是對計算機干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）
簡單的說是進程隊列的長度。Load Average 就是一段時間（1分鐘、5分鐘、15分鐘）內平均Load。【參考文章：unix Load Average Part1：How It Works】
1.2：查看指令：
w or uptime or procinfo or top
load average: 0.02, 0.27, 0.17
1 per/minute 5 per/minute 15 per/minute
1.3：如何判斷系統是否已經Over Load？
對一般的系統來說，根據cpu數量去判斷。如果平均負載始終在1.2一下，而你有2顆cup的機器。那么基本不會出現cpu不夠用的情況。也就是Load平均要小于Cpu的數量
1.4：Load與容量規劃（Capacity Planning）
一般是會根據15分鐘那個load 平均值為首先。
1.5：Load誤解：
1：系統load高一定是性能有問題。
真相：Load高也許是因為在進行cpu密集型的計算
2：系統Load高一定是CPU能力問題或數量不夠。
真相：Load高只是代表需要運行的隊列累計過多了。但隊列中的任務實際可能是耗Cpu的，也可能是耗i/0奶子其他因素的。
3：系統長期Load高，首先增加CPU
真相：Load只是表象，不是實質。增加CPU個別情況下會臨時看到Load下降，但治標不治本。
2：在Load average 高的情況下如何鑒別系統瓶頸。
是CPU不足，還是io不夠快造成或是內存不足？
2.1：查看系統負載vmstat
Vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 100152 2436 97200 289740 0 1 34 45 99 33 0 0 99 0
procs
r 列表示運行和等待cpu時間片的進程數，如果長期大于1，說明cpu不足，需要增加cpu。
b 列表示在等待資源的進程數，比如正在等待I/O、或者內存交換等。
cpu 表示cpu的使用狀態
us 列顯示了用戶方式下所花費 CPU 時間的百分比。us的值比較高時，說明用戶進程消耗的cpu時間多，但是如果長期大于50%，需要考慮優化用戶的程序。
sy 列顯示了內核進程所花費的cpu時間的百分比。這里us + sy的參考值為80%，如果us+sy 大于 80%說明可能存在CPU不足。
wa 列顯示了IO等待所占用的CPU時間的百分比。這里wa的參考值為30%，如果wa超過30%，說明IO等待嚴重，這可能是磁盤大量隨機訪問造成的，也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)。
id 列顯示了cpu處在空閑狀態的時間百分比
system 顯示采集間隔內發生的中斷數
in 列表示在某一時間間隔中觀測到的每秒設備中斷數。
cs列表示每秒產生的上下文切換次數，如當 cs 比磁盤 I/O 和網絡信息包速率高得多，都應進行進一步調查。
memory
swpd 切換到內存交換區的內存數量(k表示)。如果swpd的值不為0，或者比較大，比如超過了100m，只要si、so的值長期為0，系統性能還是正常
free 當前的空閑頁面列表中內存數量(k表示)
buff 作為buffer cache的內存數量，一般對塊設備的讀寫才需要緩沖。
cache: 作為page cache的內存數量，一般作為文件系統的cache，如果cache較大，說明用到cache的文件較多，如果此時IO中bi比較小，說明文件系統效率比較好。
swap
si 由內存進入內存交換區數量。
so由內存交換區進入內存數量。
IO
bi 從塊設備讀入數據的總量（讀磁盤）（每秒kb）。
bo 塊設備寫入數據的總量（寫磁盤）（每秒kb）
這里我們設置的bi+bo參考值為1000，如果超過1000，而且wa值較大應該考慮均衡磁盤負載，可以結合iostat輸出來分析。
2.2：查看磁盤負載iostat
每隔2秒統計一次磁盤IO信息，直到按Ctrl+C終止程序，-d 選項表示統計磁盤信息， -k 表示以每秒KB的形式顯示，-t 要求打印出時間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤IO負載狀況提供了關于自從系統啟動以來的統計信息。隨后的每一次輸出則是每個間隔之間的平均IO負載狀況。
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
rsec/s: 每秒讀扇區數。即 delta(rsect)/s
wsec/s: 每秒寫扇區數。即 delta(wsect)/s
rkB/s: 每秒讀K字節數。是 rsect/s 的一半，因為每扇區大小為512字節。(需要計算)
wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時間用于 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤
可能存在瓶頸。
idle小于70% IO壓力就較大了,一般讀取速度有較多的wait.
同時可以結合vmstat 查看查看b參數(等待資源的進程數)和wa參數(IO等待所占用的CPU時間的百分比,高過30%時IO壓力高)
另外還可以參考
一般:
svctm < await (因為同時等待的請求的等待時間被重復計算了)，
svctm的大小一般和磁盤性能有關:CPU/內存的負荷也會對其有影響，請求過多也會間接導致 svctm 的增加。
await: await的大小一般取決于服務時間(svctm) 以及 I/O 隊列的長度和 I/O 請求的發出模式。
如果 svctm 比較接近 await，說明I/O 幾乎沒有等待時間；
如果 await 遠大于 svctm，說明 I/O隊列太長，應用得到的響應時間變慢，
如果響應時間超過了用戶可以容許的范圍，這時可以考慮更換更快的磁盤，調整內核 elevator算法，優化應用，或者升級 CPU。
隊列長度(avgqu-sz)也可作為衡量系統 I/O 負荷的指標，但由于 avgqu-sz 是按照單位時間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個不錯的例子.(I/O 系統 vs. 超市排隊)
舉一個例子，我們在超市排隊 checkout 時，怎么決定該去哪個交款臺呢? 首當是看排的隊人數，5個人總比20人要快吧?除了數人頭，我們也常常看看前面人購買的東西多少，如果前面有個采購了一星期食品的大媽，那么可以考慮換個隊排了。還有就是收銀員的速度了，如果碰上了連錢都點不清楚的新手，那就有的等了。另外，時機也很重要，可能 5分鐘前還人滿為患的收款臺，現在已是人去樓空，這時候交款可是很爽啊，當然，前提是那過去的 5 分鐘里所做的事情比排隊要有意義(不過我還沒發現什么事情比排隊還無聊的)。
I/O 系統也和超市排隊有很多類似之處:
r/s+w/s 類似于交款人的總數
平均隊列長度(avgqu-sz)類似于單位時間里平均排隊人的個數
平均服務時間(svctm)類似于收銀員的收款速度
平均等待時間(await)類似于平均每人的等待時間
平均I/O數據(avgrq-sz)類似于平均每人所買的東西多少
I/O 操作率 (%util)類似于收款臺前有人排隊的時間比例。
我們可以根據這些數據分析出 I/O 請求的模式，以及 I/O 的速度和響應時間。
下面是別人寫的這個參數輸出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 輸出表明秒有 28.57 次設備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫) = 1.02+27.55 = 28.57 (次/秒) 其中寫操作占了主體 (w:r = 27:1)。
平均每次設備 I/O 操作只需要 5ms 就可以完成，但每個 I/O 請求卻需要等上 78ms，為什么? 因為發出的 I/O 請求太多 (每秒鐘約 29 個)，假設這些請求是同時發出的，那么平均等待時間可以這樣計算:
平均等待時間 = 單個 I/O 服務時間 * ( 1 + 2 + ... + 請求總數-1) / 請求總數
應用到上面的例子: 平均等待時間 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時間很接近。這反過來表明 I/O 是同時發起的。
每秒發出的 I/O 請求很多 (約 29 個)，平均隊列卻不長 (只有 2 個 左右)，這表明這 29 個請求的到來并不均勻，大部分時間 I/O 是空閑的。
一秒中有 14.29% 的時間 I/O 隊列中是有請求的，也就是說，85.71% 的時間里 I/O 系統無事可做，所有 29 個 I/O 請求都在142毫秒之內處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒內的I/O請求總共需要等待2232.8ms。所以平均隊列長度應為 2232.8ms/1000ms = 2.23，而iostat 給出的平均隊列長度 (avgqu-sz) 卻為 22.35，為什么?! 因為 iostat 中有 bug，avgqu-sz值應為 2.23，而不是 22.35。
摘要: 轉自：http://zmx.iteye.com/blog/583482Struts2 + JasperReport應用一：導PDF，Excel，HTML顯示博客分類： Struts2HTMLExcelStrutsServletXML 我用的是struts2.1.6，從struts2的自帶的demo當中可以看到它的web.xml配置與之前的有點不同，有另外一種配置：Xml代碼&n...
閱讀全文
哈哈！這個問題在我們公司也發生過。經過幾天研究終于搞定。
c3p0的connection實現類和我們想象中有出入，最大的出入就是c3p0的connection實現類的close方法不是真的將該鏈接釋放掉，而是將這個鏈接回收到可用連接池中。于是問題就來了。
c3p0的有一個maxConnection的參數，即最多鏈接數。還有一個genratNum，即當鏈接不夠用的時候自動每次生成鏈接的個數。假如將最大連接數設定為50，每次增長數設定為10，初始值為10。假如當前總共產生的鏈接數已經有49個，但是這49個鏈接不是可用連接數，那么c3p0就會增長10個。這樣一共就產生了59個。
假如你設定最大空閑時間又過長，如一個月，那么就是被close的鏈接，也不會被釋放掉，一直保留鏈接池中。
所以很快c3p0就將數據庫的鏈接用完。
解決辦法是：
1. 在代碼中當創建了一個connection（或者從池中取），必須在要在合適的時機將該鏈接close掉。
2. 合理配置最大連接數，最大空閑時間，每次增長數
3. 可以通過實行ConnectionCustomer接口，來顯式的對鏈接進行關閉，釋放資源的操作。
4. 第一點是最重要的，后兩點是輔助的。
轉自：http://www.oschina.net/question/242388_40477
P6SPY ＋SQL Profiler 監控JAVAEE SQL
一般大型的javaEE項目開發周期較長，架構，業務邏輯，代碼正確性，安全性直接影響著系統的整體性能。由于研發人員技術參差不齊，切人員流動性強，一般大型項目中存在諸多不確定性。要想避免項目后期出現重大變動，失誤，不給系統造成嚴重影響，就要從項目的初期，從代碼，注釋，對細節嚴格把控。作為研發人員當然要對自己嚴格要求，失誤最小化。下面介紹一下如果利p6spy ,sql profiler 監控javaEE sql ，至于如何分析sql，如果修改，由于本人對于sql 了解不多，不加追述，當然我也會寫，但是僅是寫一些簡單的。
1）下載p6spy 和sql profiler
2) 將p6spy-install.jar sqlprofiler-0.3-bin中的sqlprofiler.jar 放到項目的lib中
3）將sqlprofiler-0.3-bin中的spy.properties 放到web項目的classes中 ，和tomcat的bin目錄中
同時修改spy.properties 中的realdriver=oracle.jdbc.driver.OracleDriver（系統數據庫的驅動）
4）將系統的數據源配置文件中的<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
修改為：<driver-class>com.p6spy.engine.spy.P6SpyDriver</driver-class>
5）java -jar sqlprofiler.jar（是放到系統lib中的那個jar包）
D:\Program Files\Java\jdk1.5.0_17\bin>java -jar D:\nm\NetMessageCDE_BJ_CM\WEB-INF\lib\sqlprofiler.jar
cmd 日志
出現如下試圖
6）啟系統后，進行操作，sql profiler 出現sql跟蹤記錄
具體如何使用 sql profler ，上網可以搜一下，東西很多！
1、定義ehcache
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath:conf/spring/spring_ehcache.xml" />
</bean>
2、在spring中聯合oscache
<bean id="cacheFilterBean" class="com.ebizer.framework.core.filter.CacheFilter">
<property name="cacheUris">
<list>
<!--
<value>/index.html</value>
<value>/trend.html</value>
<value>/trend/newest.html</value>
-->
</list>
</property>
</bean>
3、定義ehcache的方法
<!-- Remove the following 3 beans to disable method level data cache -->
<bean id="methodCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager" />
<property name="cacheName" value="METHOD_CACHE" />
</bean>
<bean id="methodCacheLong" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager" />
<property name="cacheName" value="METHOD_CACHE_LONG" />
</bean>
<bean id="methodCacheViewHot" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager" />
<property name="cacheName" value="METHOD_CACHE_VIEW_HOT_MATCH_ITEM" />
</bean>
<bean id="methodCacheIndex" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheManager" ref="cacheManager" />
<property name="cacheName" value="METHOD_CACHE_INDEX" />
</bean>
<bean id="methodCacheInterceptorIndex" class="com.ebizer.framework.core.interceptor.MethodCacheInterceptor">
<property name="cache" ref="methodCacheIndex" />
</bean>
<bean id="methodCacheInterceptor" class="com.ebizer.framework.core.interceptor.MethodCacheInterceptor">
<property name="cache" ref="methodCache" />
</bean>
<bean id="methodCacheInterceptorLong" class="com.ebizer.framework.core.interceptor.MethodCacheInterceptor">
<property name="cache" ref="methodCacheLong" />
</bean>
<bean id="methodCacheInterceptorViewHot" class="com.ebizer.framework.core.interceptor.MethodCacheInterceptor">
<property name="cache" ref="methodCacheViewHot" />
</bean>
<bean id="methodCacheAdvisorTemplate" abstract="true" class="org.springframework.aop.support.NameMatchMethodPointcutAdvisor">
<property name="advice" ref="methodCacheInterceptor" />
</bean>
<bean id="methodCacheAdvisorTemplateLong" abstract="true" class="org.springframework.aop.support.NameMatchMethodPointcutAdvisor">
<property name="advice" ref="methodCacheInterceptorLong" />
</bean>
<bean id="methodCacheAdvisorTemplateViewHot" abstract="true" class="org.springframework.aop.support.NameMatchMethodPointcutAdvisor">
<property name="advice" ref="methodCacheInterceptorViewHot" />
</bean>
摘要: 一、因情制宜，建立“適當”的索引 建立“適當”的索引是實現查詢優化的首要前提。 索引（index）是除表之外另一重要的、用戶定義的存儲在物理介質上的數據結構。當根據索引碼的值搜索數據時，索引提供了對數據的快速訪問。事實上，沒有索引,數據庫也能根據SELECT語句成功地檢索到結果，但隨著表變得越來越大，使用“適當R...
閱讀全文
2012年6月23日
今天追蹤一個關于頁面內存暴漲，頁面響應過慢的問題。花了4個多小時，總算找到問題出在哪了。
一、問題描述
最近我們在一臺獨享服務器上搭建了Tomcat6.0.19環境，發現訪問首頁時，內存暴漲，一直不退。每次刷新內存增加近10M。一個人狂刷新一分鐘就可以把tomcat搞死機。
然后，找各種辦法解決問題。整了幾天，每天中午輪流監控Tomcat服務器，發現它掛了后就重啟。累壞了。
每天到google上面搜索答案，有人說是程序的問題，程序內存泄露。甚至問到“有沒有數據庫沒有釋放”、“有沒有使用死循環”、有沒有寫“System.gc()自動釋放內存”、有沒有“在Service層查詢時使用all()方法，查處了所有記錄”。等等。
而我一直不承認程序有問題。理由是：我們曾經將這個程序在租用的2個虛擬主機中用了近1個月。不斷維護，最后達到一個星期沒有出現一個異常的情況。
二、問題分析（關于tomcat內存溢出問題）
分析Tomcat死機的日志，發現是內存耗盡。
大致有這么一段，PSPermGen total 86016K used 86015K
到網上搜了一下，明白了jvm內存分類。然后配置內存，讓tomcat自動回收jvm內存。
當然，配置過程也遇到了很多問題，花了一天多。問題是網上的很多人都是抄來抄去，要在一大堆垃圾中選出精品不容易呀。
配了一天都只起到一定作用。比如：給tomcat設置較大內存后，tomcat可以承受到2.19G。只是再刷新就可以把他整崩潰。
最后，請了幾個牛人幫忙，一個牛人凌晨幫我們看tomcat配置。問我們，是否加了，-server參數。最后，我同事加上了-server參數。 然后，回去睡覺了，發現java.exe內存真的能回收了。很多問題也解決了。
我們配置如下：（將tomcat6的安裝版卸載，換成綠色版）
在catalina.bat的@echo off下面添加（就是第二行）
set JAVA_OPTS=-server -Xms512m -Xmx1024m -XX:MaxNewSize=512m -XX:MaxPermSize=256m
在startup.bat下面添加（讓tomcat的工具自動回收內存）
@echo off
set JAVA_OPTS=%JAVA_OPTS%
-Dcom.sun.management.jmxremote.port=1090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file="%CATALINA_HOME%\conf\logging.properties"
三、問題分析（關于頁面反應速度異常）
我們的首頁顯示餐館的信息，主要根據用戶選擇地區，然后將該地區的餐館列表和熱賣美食列表顯示出來。我們發現一個很奇怪的現象，訪問某一學校東校區時：
8個餐館：Action執行2063ms（獲取餐館列表：1220ms + 獲取熱賣美食：825ms）。
然后換成其他校區分別為：
3個餐館：Action執行 51ms (獲取餐館列表：29 + 獲取熱賣美食： 2)
3個餐館：Action執行 53ms (32 + 1)
4個餐館：Action執行 90ms (74 + 1)
看到這個數據，我就很納悶，怎么時間不成比例呢？
于是，我將8個餐館刪掉4個對比。由于有外鍵關聯，我必須要刪除其他的很多的。為了刪除一個餐館記錄，我必須刪除其他記錄多達6個表處，可見外鍵關系較為復雜。
等我刪掉后，發現東校區：
4個餐館：Action執行111ms（獲取餐館列表：53ms + 獲取熱賣美食：37ms）。
我發現這個變化太明顯了吧。然后，我懷疑那四個餐館關聯了太多東西。我查詢出來的不僅僅是餐館，可能連帶查詢了另外的6個表的記錄。
我就想到了是hbm.xml文件中設置lazy = "true"問題。
通過測試，我發現是 餐館對應訂單時，one-to-many時，lazy = "true"。這個就很明顯了。
查詢一個餐館，就把它的上百份訂單級聯查詢出來了，同時把所有菜品也級聯查詢出來了，把所有菜品分類都查詢出來了。
而就東校區的這8家餐館訂單較多，其他校區由于剛開業，訂單幾乎沒有。這下就可以解釋為什么東校區這么耗時間（當然也耗內存）。
然后，我將hbm.xml的所有lazy="true"全部去掉，恢復數據庫數據。
東校區結果如下：
8個餐館：Action執行25ms（獲取餐館列表：3ms + 獲取熱賣美食：8ms）。
四、結論：
lazy="false"使用時要慎重。例如：對與1:1的情況，使用直接影響不大，對于1:n情況就要慎重了。尤其是n成百上千時，問題就相當嚴重了。我建議最好不用。
第一次，配置和管理服務器，收獲真大呀。對我以后的編程風格都造成了深遠的影響。我會注意服務器的時間和空間效率問題。
當然測試方法比較土。先將服務器正常上線后，我會學著使用JMeter和roadrunner的工具做壓力測試，配置好服務器。
忙里偷閑！記錄下來！
轉自http://www.cnblogs.com/pyrmkj/archive/2012/06/23/2559375.html