#
摘要: 借助與spring AOP，spring提供了強(qiáng)大的基于聲明式事務(wù)管理方式，它很好對(duì)事務(wù)管理代碼和具體業(yè)務(wù)邏輯進(jìn)行了解藕，使我們?cè)赾oding過(guò)程不要去關(guān)心事務(wù)管理的邏輯。下面我們借助一個(gè)例子來(lái)將分析spring內(nèi)部的實(shí)現(xiàn)。1. 例子1.1 datasource配置[html] view plaincopyprint? <bean id="dataS...
閱讀全文
基于合理的數(shù)據(jù)庫(kù)設(shè)計(jì)，經(jīng)過(guò)深思熟慮后為表建立索引，是獲得高性能數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)。而未經(jīng)合理分析便添加索引，則會(huì)降低系統(tǒng)的總體性能。索引雖然說(shuō)提高了數(shù)據(jù)的訪(fǎng)問(wèn)速度，但同時(shí)也增加了插入、更新和刪除操作的處理時(shí)間。
是否要為表增加索引、索引建立在那些字段上，是創(chuàng)建索引前必須要考慮的問(wèn)題。解決此問(wèn)題的一個(gè)比較好的方法，就是分析應(yīng)用程序的業(yè)務(wù)處理、數(shù)據(jù)使用，為經(jīng)常被用作查詢(xún)條件、或者被要求排序的字段建立索引。基于優(yōu)化器對(duì)SQL語(yǔ)句的優(yōu)化處理，我們?cè)趧?chuàng)建索引時(shí)可以遵循下面的一般性原則：
（1）為經(jīng)常出現(xiàn)在關(guān)鍵字order by、group by、distinct后面的字段，建立索引。
在這些字段上建立索引，可以有效地避免排序操作。如果建立的是復(fù)合索引，索引的字段順序要和這些關(guān)鍵字后面的字段順序一致，否則索引不會(huì)被使用。
（2）在union等集合操作的結(jié)果集字段上，建立索引。其建立索引的目的同上。
（3）為經(jīng)常用作查詢(xún)選擇的字段，建立索引。
（4）在經(jīng)常用作表連接的屬性上，建立索引。
（5）考慮使用索引覆蓋。對(duì)數(shù)據(jù)很少被更新的表，如果用戶(hù)經(jīng)常只查詢(xún)其中的幾個(gè)字段，可以考慮在這幾個(gè)字段上建立索引，從而將表的掃描改變?yōu)樗饕膾呙琛?/span>
除了以上原則，在創(chuàng)建索引時(shí)，我們還應(yīng)當(dāng)注意以下的限制：
（1）限制表上的索引數(shù)目。
對(duì)一個(gè)存在大量更新操作的表，所建索引的數(shù)目一般不要超過(guò)3個(gè)，最多不要超過(guò)5個(gè)。索引雖說(shuō)提高了訪(fǎng)問(wèn)速度，但太多索引會(huì)影響數(shù)據(jù)的更新操作。
（2）不要在有大量相同取值的字段上，建立索引。
在這樣的字段（例如：性別）上建立索引，字段作為選擇條件時(shí)將返回大量滿(mǎn)足條件的記錄，優(yōu)化器不會(huì)使用該索引作為訪(fǎng)問(wèn)路徑。
（3）避免在取值朝一個(gè)方向增長(zhǎng)的字段（例如：日期類(lèi)型的字段）上，建立索引；對(duì)復(fù)合索引，避免將這種類(lèi)型的字段放置在最前面。
由于字段的取值總是朝一個(gè)方向增長(zhǎng)，新記錄總是存放在索引的最后一個(gè)葉頁(yè)中，從而不斷地引起該葉頁(yè)的訪(fǎng)問(wèn)競(jìng)爭(zhēng)、新葉頁(yè)的分配、中間分支頁(yè)的拆分。此外，如果所建索引是聚集索引，表中數(shù)據(jù)按照索引的排列順序存放，所有的插入操作都集中在最后一個(gè)數(shù)據(jù)頁(yè)上進(jìn)行，從而引起插入“熱點(diǎn)”。
（4）對(duì)復(fù)合索引，按照字段在查詢(xún)條件中出現(xiàn)的頻度建立索引。
在復(fù)合索引中，記錄首先按照第一個(gè)字段排序。對(duì)于在第一個(gè)字段上取值相同的記錄，系統(tǒng)再按照第二個(gè)字段的取值排序，以此類(lèi)推。因此只有復(fù)合索引的第一個(gè)字段出現(xiàn)在查詢(xún)條件中，該索引才可能被使用。
因此將應(yīng)用頻度高的字段，放置在復(fù)合索引的前面，會(huì)使系統(tǒng)最大可能地使用此索引，發(fā)揮索引的作用。
（5）刪除不再使用，或者很少被使用的索引。
表中的數(shù)據(jù)被大量更新，或者數(shù)據(jù)的使用方式被改變后，原有的一些索引可能不再被需要。數(shù)據(jù)庫(kù)管理員應(yīng)當(dāng)定期找出這些索引，將它們刪除，從而減少索引對(duì)更新操作的影響。
轉(zhuǎn)自http://www.cnblogs.com/xuhan/archive/2011/07/25/2116156.html
轉(zhuǎn)自：http://m.tkk7.com/cenwenchu/archive/2008/06/30/211712.html
SIP的第四期結(jié)束了，因?yàn)榭刂撇呗缘呢S富，早先的的壓力測(cè)試結(jié)果已經(jīng)無(wú)法反映在高并發(fā)和高壓力下SIP的運(yùn)行狀況，因此需要重新作壓力測(cè)試。跟在測(cè)試人員后面做了快一周的壓力測(cè)試，壓力測(cè)試的報(bào)告也正式出爐，本來(lái)也就算是告一段落，但第二天測(cè)試人員說(shuō)要修改報(bào)告，由于這次作壓力測(cè)試的同學(xué)是第一次作，有一個(gè)指標(biāo)沒(méi)有注意，因此需要修改幾個(gè)測(cè)試結(jié)果。那個(gè)沒(méi)有注意的指標(biāo)就是load average，他和我一樣開(kāi)始只是注意了CPU，內(nèi)存的使用狀況，而沒(méi)有太注意這個(gè)指標(biāo)，這個(gè)指標(biāo)與他們通常的限制（10左右）有差別。重新測(cè)試的結(jié)果由于這個(gè)指標(biāo)被要求壓低，最后的報(bào)告顯然不如原來(lái)的好看。自己也沒(méi)有深入過(guò)壓力測(cè)試，但是覺(jué)得不搞明白對(duì)將來(lái)機(jī)器配置和擴(kuò)容都會(huì)有影響，因此去問(wèn)了DBA和SA，得到的結(jié)果相差很大，看來(lái)不得不自己去找找問(wèn)題的根本所在了。
通過(guò)下面的幾個(gè)部分的了解，可以一步一步的找出Load Average在壓力測(cè)試中真正的作用。
CPU時(shí)間片
為了提高程序執(zhí)行效率，大家在很多應(yīng)用中都采用了多線(xiàn)程模式，這樣可以將原來(lái)的序列化執(zhí)行變?yōu)椴⑿袌?zhí)行，任務(wù)的分解以及并行執(zhí)行能夠極大地提高程序的運(yùn)行效率。但這都是代碼級(jí)別的表現(xiàn)，而硬件是如何支持的呢？那就要靠CPU的時(shí)間片模式來(lái)說(shuō)明這一切。程序的任何指令的執(zhí)行往往都會(huì)要競(jìng)爭(zhēng)CPU這個(gè)最寶貴的資源，不論你的程序分成了多少個(gè)線(xiàn)程去執(zhí)行不同的任務(wù)，他們都必須排隊(duì)等待獲取這個(gè)資源來(lái)計(jì)算和處理命令。先看看單CPU的情況。下面兩圖描述了時(shí)間片模式和非時(shí)間片模式下的線(xiàn)程執(zhí)行的情況：
圖 1 非時(shí)間片線(xiàn)程執(zhí)行情況
圖 2 非時(shí)間片線(xiàn)程執(zhí)行情況
在圖一中可以看到，任何線(xiàn)程如果都排隊(duì)等待CPU資源的獲取，那么所謂的多線(xiàn)程就沒(méi)有任何實(shí)際意義。圖二中的CPU Manager只是我虛擬的一個(gè)角色，由它來(lái)分配和管理CPU的使用狀況，此時(shí)多線(xiàn)程將會(huì)在運(yùn)行過(guò)程中都有機(jī)會(huì)得到CPU資源，也真正實(shí)現(xiàn)了在單CPU的情況下實(shí)現(xiàn)多線(xiàn)程并行處理。
多CPU的情況只是單CPU的擴(kuò)展，當(dāng)所有的CPU都滿(mǎn)負(fù)荷運(yùn)作的時(shí)候，就會(huì)對(duì)每一個(gè)CPU采用時(shí)間片的方式來(lái)提高效率。
在Linux的內(nèi)核處理過(guò)程中，每一個(gè)進(jìn)程默認(rèn)會(huì)有一個(gè)固定的時(shí)間片來(lái)執(zhí)行命令（默認(rèn)為1/100秒），這段時(shí)間內(nèi)進(jìn)程被分配到CPU，然后獨(dú)占使用。如果使用完，同時(shí)未到時(shí)間片的規(guī)定時(shí)間，那么就主動(dòng)放棄CPU的占用，如果到時(shí)間片尚未完成工作，那么CPU的使用權(quán)也會(huì)被收回，進(jìn)程將會(huì)被中斷掛起等待下一個(gè)時(shí)間片。
CPU利用率和Load Average的區(qū)別
壓力測(cè)試不僅需要對(duì)業(yè)務(wù)場(chǎng)景的并發(fā)用戶(hù)等壓力參數(shù)作模擬，同時(shí)也需要在壓力測(cè)試過(guò)程中隨時(shí)關(guān)注機(jī)器的性能情況，來(lái)確保壓力測(cè)試的有效性。當(dāng)服務(wù)器長(zhǎng)期處于一種超負(fù)荷的情況下運(yùn)行，所能接收的壓力并不是我們所認(rèn)為的可接受的壓力。就好比項(xiàng)目經(jīng)理在給一個(gè)人估工作量的時(shí)候，每天都讓這個(gè)人工作12個(gè)小時(shí)，那么所制定的項(xiàng)目計(jì)劃就不是一個(gè)合理的計(jì)劃，那個(gè)人遲早會(huì)垮掉，而影響整體的項(xiàng)目進(jìn)度。
CPU利用率在過(guò)去常常被我們這些外行認(rèn)為是判斷機(jī)器是否已經(jīng)到了滿(mǎn)負(fù)荷的一個(gè)標(biāo)準(zhǔn)，看到50%-60%的使用率就認(rèn)為機(jī)器就已經(jīng)壓到了臨界了。CPU利用率，顧名思義就是對(duì)于CPU的使用狀況，這是對(duì)一個(gè)時(shí)間段內(nèi)CPU使用狀況的統(tǒng)計(jì)，通過(guò)這個(gè)指標(biāo)可以看出在某一個(gè)時(shí)間段內(nèi)CPU被占用的情況，如果被占用時(shí)間很高，那么就需要考慮CPU是否已經(jīng)處于超負(fù)荷運(yùn)作，長(zhǎng)期超負(fù)荷運(yùn)作對(duì)于機(jī)器本身來(lái)說(shuō)是一種損害，因此必須將CPU的利用率控制在一定的比例下，以保證機(jī)器的正常運(yùn)作。
Load Average是CPU的Load，它所包含的信息不是CPU的使用率狀況，而是在一段時(shí)間內(nèi)CPU正在處理以及等待CPU處理的進(jìn)程數(shù)之和的統(tǒng)計(jì)信息，也就是CPU使用隊(duì)列的長(zhǎng)度的統(tǒng)計(jì)信息。為什么要統(tǒng)計(jì)這個(gè)信息，這個(gè)信息的對(duì)于壓力測(cè)試的影響究竟是怎么樣的，那就通過(guò)一個(gè)類(lèi)比來(lái)解釋CPU利用率和Load Average的區(qū)別以及對(duì)于壓力測(cè)試的指導(dǎo)意義。
我們將CPU就類(lèi)比為電話(huà)亭，每一個(gè)進(jìn)程都是一個(gè)需要打電話(huà)的人。現(xiàn)在一共有4個(gè)電話(huà)亭（就好比我們的機(jī)器有4核），有10個(gè)人需要打電話(huà)。現(xiàn)在使用電話(huà)的規(guī)則是管理員會(huì)按照順序給每一個(gè)人輪流分配1分鐘的使用電話(huà)時(shí)間，如果使用者在1分鐘內(nèi)使用完畢，那么可以立刻將電話(huà)使用權(quán)返還給管理員，如果到了1分鐘電話(huà)使用者還沒(méi)有使用完畢，那么需要重新排隊(duì)，等待再次分配使用。
圖 3 電話(huà)使用場(chǎng)景
上圖中對(duì)于使用電話(huà)的用戶(hù)又作了一次分類(lèi)，1min的代表這些使用者占用電話(huà)時(shí)間小于等于1min，2min表示使用者占用電話(huà)時(shí)間小于等于2min，以此類(lèi)推。根據(jù)電話(huà)使用規(guī)則，1min的用戶(hù)只需要得到一次分配即可完成通話(huà)，而其他兩類(lèi)用戶(hù)需要排隊(duì)兩次到三次。
電話(huà)的利用率 = sum (active use cpu time)/period
每一個(gè)分配到電話(huà)的使用者使用電話(huà)時(shí)間的總和去除以統(tǒng)計(jì)的時(shí)間段。這里需要注意的是是使用電話(huà)的時(shí)間總和(sum(active use cpu time))，這與占用時(shí)間的總和(sum(occupy cpu time))是有區(qū)別的。（例如一個(gè)用戶(hù)得到了一分鐘的使用權(quán)，在10秒鐘內(nèi)打了電話(huà)，然后去查詢(xún)號(hào)碼本花了20秒鐘，再用剩下的30秒打了另一個(gè)電話(huà)，那么占用了電話(huà)1分鐘，實(shí)際只是使用了40秒）
電話(huà)的Average Load體現(xiàn)的是在某一統(tǒng)計(jì)時(shí)間段內(nèi)，所有使用電話(huà)的人加上等待電話(huà)分配的人一個(gè)平均統(tǒng)計(jì)。
電話(huà)利用率的統(tǒng)計(jì)能夠反映的是電話(huà)被使用的情況，當(dāng)電話(huà)長(zhǎng)期處于被使用而沒(méi)有的到足夠的時(shí)間休息間歇，那么對(duì)于電話(huà)硬件來(lái)說(shuō)是一種超負(fù)荷的運(yùn)作，需要調(diào)整使用頻度。而電話(huà)Average Load卻從另一個(gè)角度來(lái)展現(xiàn)對(duì)于電話(huà)使用狀態(tài)的描述，Average Load越高說(shuō)明對(duì)于電話(huà)資源的競(jìng)爭(zhēng)越激烈，電話(huà)資源比較短缺。對(duì)于資源的申請(qǐng)和維護(hù)其實(shí)也是需要很大的成本，所以在這種高Average Load的情況下電話(huà)資源的長(zhǎng)期“熱競(jìng)爭(zhēng)”也是對(duì)于硬件的一種損害。
低利用率的情況下是否會(huì)有高Load Average的情況產(chǎn)生呢？理解占有時(shí)間和使用時(shí)間就可以知道，當(dāng)分配時(shí)間片以后，是否使用完全取決于使用者，因此完全可能出現(xiàn)低利用率高Load Average的情況。由此來(lái)看，僅僅從CPU的使用率來(lái)判斷CPU是否處于一種超負(fù)荷的工作狀態(tài)還是不夠的，必須結(jié)合Load Average來(lái)全局的看CPU的使用情況和申請(qǐng)情況。
所以回過(guò)頭來(lái)再看測(cè)試部對(duì)于Load Average的要求，在我們機(jī)器為8個(gè)CPU的情況下，控制在10 Load左右，也就是每一個(gè)CPU正在處理一個(gè)請(qǐng)求，同時(shí)還有2個(gè)在等待處理。看了看網(wǎng)上很多人的介紹一般來(lái)說(shuō)Load簡(jiǎn)單的計(jì)算就是2* CPU個(gè)數(shù)減去1-2左右（這個(gè)只是網(wǎng)上看來(lái)的，未必是一個(gè)標(biāo)準(zhǔn)）。
補(bǔ)充幾點(diǎn)：
1．對(duì)于CPU利用率和CPU Load Average的結(jié)果來(lái)判斷性能問(wèn)題。首先低CPU利用率不表明CPU不是瓶頸，競(jìng)爭(zhēng)CPU的隊(duì)列長(zhǎng)期保持較長(zhǎng)也是CPU超負(fù)荷的一種表現(xiàn)。對(duì)于應(yīng)用來(lái)說(shuō)可能會(huì)去花時(shí)間在I/O,Socket等方面，那么可以考慮是否后這些硬件的速度影響了整體的效率。
這里最好的樣板范例就是我在測(cè)試中發(fā)現(xiàn)的一個(gè)現(xiàn)象：SIP當(dāng)前在處理過(guò)程中，為了提高處理效率，將控制策略以及計(jì)數(shù)信息都放置在Memcached Cache里面，當(dāng)我將Memcached Cache配置擴(kuò)容一倍以后，CPU的利用率以及Load都有所下降，其實(shí)也就是在處理任務(wù)的過(guò)程中，等待Socket的返回對(duì)于CPU的競(jìng)爭(zhēng)也產(chǎn)生了影響。
2．未來(lái)多CPU編程的重要性。現(xiàn)在服務(wù)器的CPU都是多CPU了，我們的服務(wù)器處理能力已經(jīng)不再按照摩爾定律來(lái)發(fā)展。就我上面提到的電話(huà)亭場(chǎng)景來(lái)看，對(duì)于三種不同時(shí)間需求的用戶(hù)來(lái)說(shuō)，采用不同的分配順序，我們可看到的Load Average就會(huì)有不同。假設(shè)我們統(tǒng)計(jì)Load的時(shí)間段為2分鐘，如果將電話(huà)分配的順序按照：1min的用戶(hù)，2min的用戶(hù)，3min的用戶(hù)來(lái)分配，那么我們的Load Average將會(huì)最低，采用其他順序?qū)?huì)有不同的結(jié)果。所以未來(lái)的多CPU編程可以更好的提高CPU的利用率，讓程序跑的更快。
load Average
1.1：什么是Load？什么是Load Average?
Load 就是對(duì)計(jì)算機(jī)干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing）
簡(jiǎn)單的說(shuō)是進(jìn)程隊(duì)列的長(zhǎng)度。Load Average 就是一段時(shí)間（1分鐘、5分鐘、15分鐘）內(nèi)平均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：如何判斷系統(tǒng)是否已經(jīng)Over Load？
對(duì)一般的系統(tǒng)來(lái)說(shuō)，根據(jù)cpu數(shù)量去判斷。如果平均負(fù)載始終在1.2一下，而你有2顆cup的機(jī)器。那么基本不會(huì)出現(xiàn)cpu不夠用的情況。也就是Load平均要小于Cpu的數(shù)量
1.4：Load與容量規(guī)劃（Capacity Planning）
一般是會(huì)根據(jù)15分鐘那個(gè)load 平均值為首先。
1.5：Load誤解：
1：系統(tǒng)load高一定是性能有問(wèn)題。
真相：Load高也許是因?yàn)樵谶M(jìn)行cpu密集型的計(jì)算
2：系統(tǒng)Load高一定是CPU能力問(wèn)題或數(shù)量不夠。
真相：Load高只是代表需要運(yùn)行的隊(duì)列累計(jì)過(guò)多了。但隊(duì)列中的任務(wù)實(shí)際可能是耗Cpu的，也可能是耗i/0奶子其他因素的。
3：系統(tǒng)長(zhǎng)期Load高，首先增加CPU
真相：Load只是表象，不是實(shí)質(zhì)。增加CPU個(gè)別情況下會(huì)臨時(shí)看到Load下降，但治標(biāo)不治本。
2：在Load average 高的情況下如何鑒別系統(tǒng)瓶頸。
是CPU不足，還是io不夠快造成或是內(nèi)存不足？
2.1：查看系統(tǒng)負(fù)載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 列表示運(yùn)行和等待cpu時(shí)間片的進(jìn)程數(shù)，如果長(zhǎng)期大于1，說(shuō)明cpu不足，需要增加cpu。
b 列表示在等待資源的進(jìn)程數(shù)，比如正在等待I/O、或者內(nèi)存交換等。
cpu 表示cpu的使用狀態(tài)
us 列顯示了用戶(hù)方式下所花費(fèi) CPU 時(shí)間的百分比。us的值比較高時(shí)，說(shuō)明用戶(hù)進(jìn)程消耗的cpu時(shí)間多，但是如果長(zhǎng)期大于50%，需要考慮優(yōu)化用戶(hù)的程序。
sy 列顯示了內(nèi)核進(jìn)程所花費(fèi)的cpu時(shí)間的百分比。這里us + sy的參考值為80%，如果us+sy 大于 80%說(shuō)明可能存在CPU不足。
wa 列顯示了IO等待所占用的CPU時(shí)間的百分比。這里wa的參考值為30%，如果wa超過(guò)30%，說(shuō)明IO等待嚴(yán)重，這可能是磁盤(pán)大量隨機(jī)訪(fǎng)問(wèn)造成的，也可能磁盤(pán)或者磁盤(pán)訪(fǎng)問(wèn)控制器的帶寬瓶頸造成的(主要是塊操作)。
id 列顯示了cpu處在空閑狀態(tài)的時(shí)間百分比
system 顯示采集間隔內(nèi)發(fā)生的中斷數(shù)
in 列表示在某一時(shí)間間隔中觀測(cè)到的每秒設(shè)備中斷數(shù)。
cs列表示每秒產(chǎn)生的上下文切換次數(shù)，如當(dāng) cs 比磁盤(pán) I/O 和網(wǎng)絡(luò)信息包速率高得多，都應(yīng)進(jìn)行進(jìn)一步調(diào)查。
memory
swpd 切換到內(nèi)存交換區(qū)的內(nèi)存數(shù)量(k表示)。如果swpd的值不為0，或者比較大，比如超過(guò)了100m，只要si、so的值長(zhǎng)期為0，系統(tǒng)性能還是正常
free 當(dāng)前的空閑頁(yè)面列表中內(nèi)存數(shù)量(k表示)
buff 作為buffer cache的內(nèi)存數(shù)量，一般對(duì)塊設(shè)備的讀寫(xiě)才需要緩沖。
cache: 作為page cache的內(nèi)存數(shù)量，一般作為文件系統(tǒng)的cache，如果cache較大，說(shuō)明用到cache的文件較多，如果此時(shí)IO中bi比較小，說(shuō)明文件系統(tǒng)效率比較好。
swap
si 由內(nèi)存進(jìn)入內(nèi)存交換區(qū)數(shù)量。
so由內(nèi)存交換區(qū)進(jìn)入內(nèi)存數(shù)量。
IO
bi 從塊設(shè)備讀入數(shù)據(jù)的總量（讀磁盤(pán)）（每秒kb）。
bo 塊設(shè)備寫(xiě)入數(shù)據(jù)的總量（寫(xiě)磁盤(pán)）（每秒kb）
這里我們?cè)O(shè)置的bi+bo參考值為1000，如果超過(guò)1000，而且wa值較大應(yīng)該考慮均衡磁盤(pán)負(fù)載，可以結(jié)合iostat輸出來(lái)分析。
2.2：查看磁盤(pán)負(fù)載iostat
每隔2秒統(tǒng)計(jì)一次磁盤(pán)IO信息，直到按Ctrl+C終止程序，-d 選項(xiàng)表示統(tǒng)計(jì)磁盤(pán)信息， -k 表示以每秒KB的形式顯示，-t 要求打印出時(shí)間信息，2 表示每隔 2 秒輸出一次。第一次輸出的磁盤(pán)IO負(fù)載狀況提供了關(guān)于自從系統(tǒng)啟動(dòng)以來(lái)的統(tǒng)計(jì)信息。隨后的每一次輸出則是每個(gè)間隔之間的平均IO負(fù)載狀況。
# 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: 每秒進(jìn)行 merge 的讀操作數(shù)目。即 delta(rmerge)/s
wrqm/s: 每秒進(jìn)行 merge 的寫(xiě)操作數(shù)目。即 delta(wmerge)/s
r/s: 每秒完成的讀 I/O 設(shè)備次數(shù)。即 delta(rio)/s
w/s: 每秒完成的寫(xiě) I/O 設(shè)備次數(shù)。即 delta(wio)/s
rsec/s: 每秒讀扇區(qū)數(shù)。即 delta(rsect)/s
wsec/s: 每秒寫(xiě)扇區(qū)數(shù)。即 delta(wsect)/s
rkB/s: 每秒讀K字節(jié)數(shù)。是 rsect/s 的一半，因?yàn)槊可葏^(qū)大小為512字節(jié)。(需要計(jì)算)
wkB/s: 每秒寫(xiě)K字節(jié)數(shù)。是 wsect/s 的一半。(需要計(jì)算)
avgrq-sz: 平均每次設(shè)備I/O操作的數(shù)據(jù)大小 (扇區(qū))。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O隊(duì)列長(zhǎng)度。即 delta(aveq)/s/1000 (因?yàn)閍veq的單位為毫秒)。
await: 平均每次設(shè)備I/O操作的等待時(shí)間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次設(shè)備I/O操作的服務(wù)時(shí)間 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的時(shí)間用于 I/O 操作，或者說(shuō)一秒中有多少時(shí)間 I/O 隊(duì)列是非空的。即 delta(use)/s/1000 (因?yàn)閡se的單位為毫秒)
如果 %util 接近 100%，說(shuō)明產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)已經(jīng)滿(mǎn)負(fù)荷，該磁盤(pán)
可能存在瓶頸。
idle小于70% IO壓力就較大了,一般讀取速度有較多的wait.
同時(shí)可以結(jié)合vmstat 查看查看b參數(shù)(等待資源的進(jìn)程數(shù))和wa參數(shù)(IO等待所占用的CPU時(shí)間的百分比,高過(guò)30%時(shí)IO壓力高)
另外還可以參考
一般:
svctm < await (因?yàn)橥瑫r(shí)等待的請(qǐng)求的等待時(shí)間被重復(fù)計(jì)算了)，
svctm的大小一般和磁盤(pán)性能有關(guān):CPU/內(nèi)存的負(fù)荷也會(huì)對(duì)其有影響，請(qǐng)求過(guò)多也會(huì)間接導(dǎo)致 svctm 的增加。
await: await的大小一般取決于服務(wù)時(shí)間(svctm) 以及 I/O 隊(duì)列的長(zhǎng)度和 I/O 請(qǐng)求的發(fā)出模式。
如果 svctm 比較接近 await，說(shuō)明I/O 幾乎沒(méi)有等待時(shí)間；
如果 await 遠(yuǎn)大于 svctm，說(shuō)明 I/O隊(duì)列太長(zhǎng)，應(yīng)用得到的響應(yīng)時(shí)間變慢，
如果響應(yīng)時(shí)間超過(guò)了用戶(hù)可以容許的范圍，這時(shí)可以考慮更換更快的磁盤(pán)，調(diào)整內(nèi)核 elevator算法，優(yōu)化應(yīng)用，或者升級(jí) CPU。
隊(duì)列長(zhǎng)度(avgqu-sz)也可作為衡量系統(tǒng) I/O 負(fù)荷的指標(biāo)，但由于 avgqu-sz 是按照單位時(shí)間的平均值，所以不能反映瞬間的 I/O 洪水。
別人一個(gè)不錯(cuò)的例子.(I/O 系統(tǒng) vs. 超市排隊(duì))
舉一個(gè)例子，我們?cè)诔信抨?duì) checkout 時(shí)，怎么決定該去哪個(gè)交款臺(tái)呢? 首當(dāng)是看排的隊(duì)人數(shù)，5個(gè)人總比20人要快吧?除了數(shù)人頭，我們也常常看看前面人購(gòu)買(mǎi)的東西多少，如果前面有個(gè)采購(gòu)了一星期食品的大媽?zhuān)敲纯梢钥紤]換個(gè)隊(duì)排了。還有就是收銀員的速度了，如果碰上了連錢(qián)都點(diǎn)不清楚的新手，那就有的等了。另外，時(shí)機(jī)也很重要，可能 5分鐘前還人滿(mǎn)為患的收款臺(tái)，現(xiàn)在已是人去樓空，這時(shí)候交款可是很爽啊，當(dāng)然，前提是那過(guò)去的 5 分鐘里所做的事情比排隊(duì)要有意義(不過(guò)我還沒(méi)發(fā)現(xiàn)什么事情比排隊(duì)還無(wú)聊的)。
I/O 系統(tǒng)也和超市排隊(duì)有很多類(lèi)似之處:
r/s+w/s 類(lèi)似于交款人的總數(shù)
平均隊(duì)列長(zhǎng)度(avgqu-sz)類(lèi)似于單位時(shí)間里平均排隊(duì)人的個(gè)數(shù)
平均服務(wù)時(shí)間(svctm)類(lèi)似于收銀員的收款速度
平均等待時(shí)間(await)類(lèi)似于平均每人的等待時(shí)間
平均I/O數(shù)據(jù)(avgrq-sz)類(lèi)似于平均每人所買(mǎi)的東西多少
I/O 操作率 (%util)類(lèi)似于收款臺(tái)前有人排隊(duì)的時(shí)間比例。
我們可以根據(jù)這些數(shù)據(jù)分析出 I/O 請(qǐng)求的模式，以及 I/O 的速度和響應(yīng)時(shí)間。
下面是別人寫(xiě)的這個(gè)參數(shù)輸出的分析
# 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 次設(shè)備 I/O 操作: 總IO(io)/s = r/s(讀) +w/s(寫(xiě)) = 1.02+27.55 = 28.57 (次/秒) 其中寫(xiě)操作占了主體 (w:r = 27:1)。
平均每次設(shè)備 I/O 操作只需要 5ms 就可以完成，但每個(gè) I/O 請(qǐng)求卻需要等上 78ms，為什么? 因?yàn)榘l(fā)出的 I/O 請(qǐng)求太多 (每秒鐘約 29 個(gè))，假設(shè)這些請(qǐng)求是同時(shí)發(fā)出的，那么平均等待時(shí)間可以這樣計(jì)算:
平均等待時(shí)間 = 單個(gè) I/O 服務(wù)時(shí)間 * ( 1 + 2 + ... + 請(qǐng)求總數(shù)-1) / 請(qǐng)求總數(shù)
應(yīng)用到上面的例子: 平均等待時(shí)間 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 給出的78ms 的平均等待時(shí)間很接近。這反過(guò)來(lái)表明 I/O 是同時(shí)發(fā)起的。
每秒發(fā)出的 I/O 請(qǐng)求很多 (約 29 個(gè))，平均隊(duì)列卻不長(zhǎng) (只有 2 個(gè) 左右)，這表明這 29 個(gè)請(qǐng)求的到來(lái)并不均勻，大部分時(shí)間 I/O 是空閑的。
一秒中有 14.29% 的時(shí)間 I/O 隊(duì)列中是有請(qǐng)求的，也就是說(shuō)，85.71% 的時(shí)間里 I/O 系統(tǒng)無(wú)事可做，所有 29 個(gè) I/O 請(qǐng)求都在142毫秒之內(nèi)處理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s=78.21 * delta(io)/s = 78.21*28.57 =2232.8，表明每秒內(nèi)的I/O請(qǐng)求總共需要等待2232.8ms。所以平均隊(duì)列長(zhǎng)度應(yīng)為 2232.8ms/1000ms = 2.23，而iostat 給出的平均隊(duì)列長(zhǎng)度 (avgqu-sz) 卻為 22.35，為什么?! 因?yàn)?iostat 中有 bug，avgqu-sz值應(yīng)為 2.23，而不是 22.35。
摘要: 轉(zhuǎn)自：http://zmx.iteye.com/blog/583482Struts2 + JasperReport應(yīng)用一：導(dǎo)PDF，Excel，HTML顯示博客分類(lèi)： Struts2HTMLExcelStrutsServletXML 我用的是struts2.1.6，從struts2的自帶的demo當(dāng)中可以看到它的web.xml配置與之前的有點(diǎn)不同，有另外一種配置：Xml代碼&n...
閱讀全文
哈哈！這個(gè)問(wèn)題在我們公司也發(fā)生過(guò)。經(jīng)過(guò)幾天研究終于搞定。
c3p0的connection實(shí)現(xiàn)類(lèi)和我們想象中有出入，最大的出入就是c3p0的connection實(shí)現(xiàn)類(lèi)的close方法不是真的將該鏈接釋放掉，而是將這個(gè)鏈接回收到可用連接池中。于是問(wèn)題就來(lái)了。
c3p0的有一個(gè)maxConnection的參數(shù)，即最多鏈接數(shù)。還有一個(gè)genratNum，即當(dāng)鏈接不夠用的時(shí)候自動(dòng)每次生成鏈接的個(gè)數(shù)。假如將最大連接數(shù)設(shè)定為50，每次增長(zhǎng)數(shù)設(shè)定為10，初始值為10。假如當(dāng)前總共產(chǎn)生的鏈接數(shù)已經(jīng)有49個(gè)，但是這49個(gè)鏈接不是可用連接數(shù)，那么c3p0就會(huì)增長(zhǎng)10個(gè)。這樣一共就產(chǎn)生了59個(gè)。
假如你設(shè)定最大空閑時(shí)間又過(guò)長(zhǎng)，如一個(gè)月，那么就是被close的鏈接，也不會(huì)被釋放掉，一直保留鏈接池中。
所以很快c3p0就將數(shù)據(jù)庫(kù)的鏈接用完。
解決辦法是：
1. 在代碼中當(dāng)創(chuàng)建了一個(gè)connection（或者從池中取），必須在要在合適的時(shí)機(jī)將該鏈接close掉。
2. 合理配置最大連接數(shù)，最大空閑時(shí)間，每次增長(zhǎng)數(shù)
3. 可以通過(guò)實(shí)行ConnectionCustomer接口，來(lái)顯式的對(duì)鏈接進(jìn)行關(guān)閉，釋放資源的操作。
4. 第一點(diǎn)是最重要的，后兩點(diǎn)是輔助的。
轉(zhuǎn)自：http://www.oschina.net/question/242388_40477
P6SPY ＋SQL Profiler 監(jiān)控JAVAEE SQL
一般大型的javaEE項(xiàng)目開(kāi)發(fā)周期較長(zhǎng)，架構(gòu)，業(yè)務(wù)邏輯，代碼正確性，安全性直接影響著系統(tǒng)的整體性能。由于研發(fā)人員技術(shù)參差不齊，切人員流動(dòng)性強(qiáng)，一般大型項(xiàng)目中存在諸多不確定性。要想避免項(xiàng)目后期出現(xiàn)重大變動(dòng)，失誤，不給系統(tǒng)造成嚴(yán)重影響，就要從項(xiàng)目的初期，從代碼，注釋?zhuān)瑢?duì)細(xì)節(jié)嚴(yán)格把控。作為研發(fā)人員當(dāng)然要對(duì)自己嚴(yán)格要求，失誤最小化。下面介紹一下如果利p6spy ,sql profiler 監(jiān)控javaEE sql ，至于如何分析sql，如果修改，由于本人對(duì)于sql 了解不多，不加追述，當(dāng)然我也會(huì)寫(xiě)，但是僅是寫(xiě)一些簡(jiǎn)單的。
1）下載p6spy 和sql profiler
2) 將p6spy-install.jar sqlprofiler-0.3-bin中的sqlprofiler.jar 放到項(xiàng)目的lib中
3）將sqlprofiler-0.3-bin中的spy.properties 放到web項(xiàng)目的classes中 ，和tomcat的bin目錄中
同時(shí)修改spy.properties 中的realdriver=oracle.jdbc.driver.OracleDriver（系統(tǒng)數(shù)據(jù)庫(kù)的驅(qū)動(dòng)）
4）將系統(tǒng)的數(shù)據(jù)源配置文件中的<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
修改為：<driver-class>com.p6spy.engine.spy.P6SpyDriver</driver-class>
5）java -jar sqlprofiler.jar（是放到系統(tǒng)lib中的那個(gè)jar包）
D:\Program Files\Java\jdk1.5.0_17\bin>java -jar D:\nm\NetMessageCDE_BJ_CM\WEB-INF\lib\sqlprofiler.jar
cmd 日志
出現(xiàn)如下試圖
6）啟系統(tǒng)后，進(jìn)行操作，sql profiler 出現(xiàn)sql跟蹤記錄
具體如何使用 sql profler ，上網(wǎng)可以搜一下，東西很多！
1、定義ehcache
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
<property name="configLocation" value="classpath:conf/spring/spring_ehcache.xml" />
</bean>
2、在spring中聯(lián)合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>
摘要: 一、因情制宜，建立“適當(dāng)”的索引 建立“適當(dāng)”的索引是實(shí)現(xiàn)查詢(xún)優(yōu)化的首要前提。 索引（index）是除表之外另一重要的、用戶(hù)定義的存儲(chǔ)在物理介質(zhì)上的數(shù)據(jù)結(jié)構(gòu)。當(dāng)根據(jù)索引碼的值搜索數(shù)據(jù)時(shí)，索引提供了對(duì)數(shù)據(jù)的快速訪(fǎng)問(wèn)。事實(shí)上，沒(méi)有索引,數(shù)據(jù)庫(kù)也能根據(jù)SELECT語(yǔ)句成功地檢索到結(jié)果，但隨著表變得越來(lái)越大，使用“適當(dāng)R...
閱讀全文
2012年6月23日
今天追蹤一個(gè)關(guān)于頁(yè)面內(nèi)存暴漲，頁(yè)面響應(yīng)過(guò)慢的問(wèn)題。花了4個(gè)多小時(shí)，總算找到問(wèn)題出在哪了。
一、問(wèn)題描述
最近我們?cè)谝慌_(tái)獨(dú)享服務(wù)器上搭建了Tomcat6.0.19環(huán)境，發(fā)現(xiàn)訪(fǎng)問(wèn)首頁(yè)時(shí)，內(nèi)存暴漲，一直不退。每次刷新內(nèi)存增加近10M。一個(gè)人狂刷新一分鐘就可以把tomcat搞死機(jī)。
然后，找各種辦法解決問(wèn)題。整了幾天，每天中午輪流監(jiān)控Tomcat服務(wù)器，發(fā)現(xiàn)它掛了后就重啟。累壞了。
每天到google上面搜索答案，有人說(shuō)是程序的問(wèn)題，程序內(nèi)存泄露。甚至問(wèn)到“有沒(méi)有數(shù)據(jù)庫(kù)沒(méi)有釋放”、“有沒(méi)有使用死循環(huán)”、有沒(méi)有寫(xiě)“System.gc()自動(dòng)釋放內(nèi)存”、有沒(méi)有“在Service層查詢(xún)時(shí)使用all()方法，查處了所有記錄”。等等。
而我一直不承認(rèn)程序有問(wèn)題。理由是：我們?cè)?jīng)將這個(gè)程序在租用的2個(gè)虛擬主機(jī)中用了近1個(gè)月。不斷維護(hù)，最后達(dá)到一個(gè)星期沒(méi)有出現(xiàn)一個(gè)異常的情況。
二、問(wèn)題分析（關(guān)于tomcat內(nèi)存溢出問(wèn)題）
分析Tomcat死機(jī)的日志，發(fā)現(xiàn)是內(nèi)存耗盡。
大致有這么一段，PSPermGen total 86016K used 86015K
到網(wǎng)上搜了一下，明白了jvm內(nèi)存分類(lèi)。然后配置內(nèi)存，讓tomcat自動(dòng)回收jvm內(nèi)存。
當(dāng)然，配置過(guò)程也遇到了很多問(wèn)題，花了一天多。問(wèn)題是網(wǎng)上的很多人都是抄來(lái)抄去，要在一大堆垃圾中選出精品不容易呀。
配了一天都只起到一定作用。比如：給tomcat設(shè)置較大內(nèi)存后，tomcat可以承受到2.19G。只是再刷新就可以把他整崩潰。
最后，請(qǐng)了幾個(gè)牛人幫忙，一個(gè)牛人凌晨幫我們看tomcat配置。問(wèn)我們，是否加了，-server參數(shù)。最后，我同事加上了-server參數(shù)。 然后，回去睡覺(jué)了，發(fā)現(xiàn)java.exe內(nèi)存真的能回收了。很多問(wèn)題也解決了。
我們配置如下：（將tomcat6的安裝版卸載，換成綠色版）
在catalina.bat的@echo off下面添加（就是第二行）
set JAVA_OPTS=-server -Xms512m -Xmx1024m -XX:MaxNewSize=512m -XX:MaxPermSize=256m
在startup.bat下面添加（讓tomcat的工具自動(dòng)回收內(nèi)存）
@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"
三、問(wèn)題分析（關(guān)于頁(yè)面反應(yīng)速度異常）
我們的首頁(yè)顯示餐館的信息，主要根據(jù)用戶(hù)選擇地區(qū)，然后將該地區(qū)的餐館列表和熱賣(mài)美食列表顯示出來(lái)。我們發(fā)現(xiàn)一個(gè)很奇怪的現(xiàn)象，訪(fǎng)問(wèn)某一學(xué)校東校區(qū)時(shí)：
8個(gè)餐館：Action執(zhí)行2063ms（獲取餐館列表：1220ms + 獲取熱賣(mài)美食：825ms）。
然后換成其他校區(qū)分別為：
3個(gè)餐館：Action執(zhí)行 51ms (獲取餐館列表：29 + 獲取熱賣(mài)美食： 2)
3個(gè)餐館：Action執(zhí)行 53ms (32 + 1)
4個(gè)餐館：Action執(zhí)行 90ms (74 + 1)
看到這個(gè)數(shù)據(jù)，我就很納悶，怎么時(shí)間不成比例呢？
于是，我將8個(gè)餐館刪掉4個(gè)對(duì)比。由于有外鍵關(guān)聯(lián)，我必須要?jiǎng)h除其他的很多的。為了刪除一個(gè)餐館記錄，我必須刪除其他記錄多達(dá)6個(gè)表處，可見(jiàn)外鍵關(guān)系較為復(fù)雜。
等我刪掉后，發(fā)現(xiàn)東校區(qū)：
4個(gè)餐館：Action執(zhí)行111ms（獲取餐館列表：53ms + 獲取熱賣(mài)美食：37ms）。
我發(fā)現(xiàn)這個(gè)變化太明顯了吧。然后，我懷疑那四個(gè)餐館關(guān)聯(lián)了太多東西。我查詢(xún)出來(lái)的不僅僅是餐館，可能連帶查詢(xún)了另外的6個(gè)表的記錄。
我就想到了是hbm.xml文件中設(shè)置lazy = "true"問(wèn)題。
通過(guò)測(cè)試，我發(fā)現(xiàn)是 餐館對(duì)應(yīng)訂單時(shí)，one-to-many時(shí)，lazy = "true"。這個(gè)就很明顯了。
查詢(xún)一個(gè)餐館，就把它的上百份訂單級(jí)聯(lián)查詢(xún)出來(lái)了，同時(shí)把所有菜品也級(jí)聯(lián)查詢(xún)出來(lái)了，把所有菜品分類(lèi)都查詢(xún)出來(lái)了。
而就東校區(qū)的這8家餐館訂單較多，其他校區(qū)由于剛開(kāi)業(yè)，訂單幾乎沒(méi)有。這下就可以解釋為什么東校區(qū)這么耗時(shí)間（當(dāng)然也耗內(nèi)存）。
然后，我將hbm.xml的所有l(wèi)azy="true"全部去掉，恢復(fù)數(shù)據(jù)庫(kù)數(shù)據(jù)。
東校區(qū)結(jié)果如下：
8個(gè)餐館：Action執(zhí)行25ms（獲取餐館列表：3ms + 獲取熱賣(mài)美食：8ms）。
四、結(jié)論：
lazy="false"使用時(shí)要慎重。例如：對(duì)與1:1的情況，使用直接影響不大，對(duì)于1:n情況就要慎重了。尤其是n成百上千時(shí)，問(wèn)題就相當(dāng)嚴(yán)重了。我建議最好不用。
第一次，配置和管理服務(wù)器，收獲真大呀。對(duì)我以后的編程風(fēng)格都造成了深遠(yuǎn)的影響。我會(huì)注意服務(wù)器的時(shí)間和空間效率問(wèn)題。
當(dāng)然測(cè)試方法比較土。先將服務(wù)器正常上線(xiàn)后，我會(huì)學(xué)著使用JMeter和roadrunner的工具做壓力測(cè)試，配置好服務(wù)器。
忙里偷閑！記錄下來(lái)！
轉(zhuǎn)自http://www.cnblogs.com/pyrmkj/archive/2012/06/23/2559375.html