語錄一
某天,停車,圖方便隨便停在路邊,抱怨了兩句,ld隨即頂回一句:“只要有邊就能停”posted @ 2008-11-18 23:32 tacy lee 閱讀(246) | 評論 (0) | 編輯 收藏
2007年10月30日 #
posted @ 2008-11-18 23:32 tacy lee 閱讀(246) | 評論 (0) | 編輯 收藏
一直認(rèn)為lob類型的性能要好過long,但是之前只了解到long的種種限制,oracle也是不推薦使用long類型,這幾天由于一個項目問題,產(chǎn)品里面一個表字段用了long類型,分析下來操作long的時候,性能有所影響,想把它改成lob,就簡單驗證了一下
首先創(chuàng)建兩個測試表:
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼,往兩個表里面各插入100條數(shù)據(jù),保證插入數(shù)據(jù)是一樣的,lob字段長度為10k(如果小于4k,oracle可以把它保存到到表內(nèi),不會存儲在表外,性能沒有問題,這個我基本確定,而且我們應(yīng)用中這個字段經(jīng)常會超過4k)。
做一個簡單查詢對比一下:
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統(tǒng)計信息
----------------------------------------------------------
331 recursive calls
0 db block gets
69 consistent gets
4 physical reads
0 redo size
1278 bytes sent via SQL*Net to client
837 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from test_long where a=1;
統(tǒng)計信息
----------------------------------------------------------
236 recursive calls
0 db block gets
43 consistent gets
0 physical reads
0 redo size
675 bytes sent via SQL*Net to client
531 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
對比一下,long開銷比lob小,當(dāng)然你可以把lob字段啟用緩存,把4次物理讀去掉,但還是多了(73-43)次邏輯讀,update也試了一下,lob產(chǎn)生的redo比long大,就不列出來了,有興趣的可以自己試試
測試下來,看來之前的認(rèn)識不對,不確定的東西最好還是動手試試,當(dāng)然對于新應(yīng)用,還是不建議用long,畢竟oracle已經(jīng)廢棄它了。
posted @ 2008-06-24 01:18 tacy lee 閱讀(456) | 評論 (0) | 編輯 收藏
用遠(yuǎn)程桌面連接登入服務(wù)器的時候,你可能會經(jīng)常碰到下面的情況:
也就是說,服務(wù)器的連接數(shù)已經(jīng)滿了,很多時候,可能是別人異常斷開連接,導(dǎo)致連接沒有釋放,一般這時候你需要去機(jī)房登入服務(wù)器斷開連接,其實windows提供了tsdiscon命令來做這事情
posted @ 2008-06-22 17:12 tacy lee 閱讀(468) | 評論 (0) | 編輯 收藏
有時候,我們可能希望看到lr的出錯頁面:比如lr出錯,但是后臺服務(wù)器沒有錯誤日志,這時候,我們希望能看到錯誤頁面的內(nèi)容來判斷問題出在什么地方,但是lr沒有提供類似的功能
我們可以通過一種變通的辦法來實現(xiàn):
首先找到你出錯的頁面,保存該頁面到參數(shù)里面:
web_set_max_html_param_len(“2048”);
web_reg_save_param(“FILED”,”LB=”,”RB=”,”Search=Body”,LAST);
然后輸出到日志里面: lr_output_message(”#######################################%s”,lr_eval_string(”{FILED}”));
修改lr run-time的幾個設(shè)置:
1、Always send messages
2、continue on error (這樣才能保證運(yùn)行l(wèi)r_output_message)
這樣lr會把所有的lr_output_message輸出保存到日志文件
當(dāng)然你不要下載資源文件,否則保存到的就不是html頁面了,可能是一個gif :(
最后,結(jié)合lr controller的錯誤信息,定位到出錯的vuser id,查看該vuser的log文件就能看到錯誤頁面了
非常有效的一個小技巧,用它解決了一個難纏的問題。
posted @ 2008-05-28 23:05 tacy lee 閱讀(834) | 評論 (3) | 編輯 收藏
posted @ 2008-05-14 10:17 tacy lee 閱讀(243) | 評論 (0) | 編輯 收藏
posted @ 2008-04-14 20:38 tacy lee 閱讀(4456) | 評論 (2) | 編輯 收藏
Sybase ASE有三種鎖模式:AllPages,DataPages,DataRows
Sybase的數(shù)據(jù)有table pages和index pages,最小分配單位為pages,不同的鎖模式對于table pages和index pages有不同的表現(xiàn),具體如下:
Locking Schema | Locks on Index | Locks on Data |
All Pages | Page | Page |
DataPages | Not locked | Page |
DataRows | Not locked | Row |
如上表所示:
1、AllPages鎖模式對于并發(fā)的限制最高,他對index pages和table pages都加頁鎖(當(dāng)頁被鎖住的時候,頁上的所有rows都不能被其他session訪問)
2、DataPages對table pages加頁鎖
3、DataRows:強(qiáng)烈建議用這個鎖模式,對于oltp應(yīng)用,如果用前兩種鎖模式會導(dǎo)致頻繁死鎖
另外,DataPages和DataRows對于index pages的控制采用latch方式,一種輕量級的鎖機(jī)制(熟悉oracle會比較清楚)
對于Sybase ASE來說,鎖是非常寶貴的資源,不要長時間持有鎖,所以一般我們在寫應(yīng)用的時候盡量減少長事務(wù)
另:Sybase ASE缺省的事務(wù)隔離級別:Read Committed
posted @ 2008-04-01 10:50 tacy lee 閱讀(926) | 評論 (0) | 編輯 收藏
一個用戶點擊就是一個用戶請求,一個webservice類似的調(diào)用也算一個請求,等等
一個用戶在某個時間點上當(dāng)然只能發(fā)起一個用戶請求,一個用戶請求就是一個并發(fā)
我們一般糾纏在同一事物并發(fā)還是不同事務(wù)并發(fā)。
可能在一個時間點上,有100個用戶在發(fā)送瀏覽,查詢動作,10個用戶在下訂單,5個用戶在做付款動作,你說這個時間點上有多少個并發(fā)請求,當(dāng)然是115個了
衡量一個系統(tǒng)性能主要靠的就是這個吞吐量(tps)
當(dāng)然我們也非常關(guān)心同時100個用戶并發(fā)下訂單的時候系統(tǒng)是否能支撐(這是通常我們大部分人理解的并發(fā)),我們會說這是核心業(yè)務(wù),我們要得出數(shù)據(jù)(是否要考慮背景業(yè)務(wù)呢,呵呵,很難說的清楚,我一般就不考慮)
posted @ 2008-03-18 15:33 tacy lee 閱讀(291) | 評論 (0) | 編輯 收藏
某項目,年前開始報OOM,頻率保持在一月一次,發(fā)生OOM的時候,heap free size還有7~800M,比較奇怪,年后系統(tǒng)上集群,系統(tǒng)發(fā)生OOM的頻率開始變得頻繁,基本在4-5天,由于用的是sun jdk 1.4.2_08,無法獲取到heap dump,建議用戶升級到1.4.2_14(該版本以后sun添加了HeapDumpOnOutOfMemoryError參數(shù),便于獲取dump幫助診斷該類問題),4天之后,我們獲取到了heapdump文件,通過對dump的分析,基本上排除了對象泄漏。
根據(jù)環(huán)境(64bit Solaris + 32bit JDK),客戶把Heap最大設(shè)置為2G,開始懷疑32bit JDK無法分配這么大的Heap,經(jīng)過驗證,不存在這樣的問題(sun網(wǎng)站也有相關(guān)說明,在solaris 64bit系統(tǒng)上,32bit jdk最大可以設(shè)置到4G)
但是從dump看到application classes loader大小已經(jīng)到了60M以上,有點懷疑Perm區(qū)設(shè)置太小導(dǎo)致,查了一下sun的文檔,Perm區(qū)缺省大小為64M,估計是應(yīng)用加載太多classes導(dǎo)致Perm區(qū)溢出,
我們也簡單模擬了一下Perm溢出,強(qiáng)制設(shè)置max perm大小為32M,并對GC進(jìn)行了監(jiān)控,結(jié)果和我們預(yù)想的一致,看下面的gc log:
151.836: [Full GC 151.836: [Tenured: 25735K->25736K(1048576K), 0.8380858 secs] 25911K->25736K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8382804 secs]
152.676: [Full GC 152.676: [Tenured: 25736K->25722K(1048576K), 0.8464782 secs] 25752K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8466638 secs]
153.525: [Full GC 153.525: [Tenured: 25722K->25724K(1048576K), 0.8419056 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8420986 secs]
154.368: [Full GC 154.368: [Tenured: 25724K->25724K(1048576K), 0.8398816 secs] 25724K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8400498 secs]
155.212: [Full GC 155.212: [Tenured: 25724K->25725K(1048576K), 0.8365448 secs] 25788K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8367370 secs]
156.050: [Full GC 156.050: [Tenured: 25725K->25722K(1048576K), 0.8422488 secs] 25725K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8424328 secs]
156.895: [Full GC 156.895: [Tenured: 25722K->25724K(1048576K), 0.8443532 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8445450 secs]
157.740: [Full GC 157.741: [Tenured: 25724K->25724K(1048576K), 0.8427754 secs] 25740K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8429634 secs]
158.587: [Full GC 158.588: [Tenured: 25724K->25726K(1048576K), 0.8352290 secs] 25820K->25726K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8354212 secs]
159.424: [Full GC 159.424: [Tenured: 25726K->25723K(1048576K), 0.8435336 secs] 25726K->25723K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8437092 secs]
160.270: [Full GC 160.270: [Tenured: 25723K->25725K(1048576K), 0.8477722 secs] 25739K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8479596 secs]
161.119: [Full GC 161.119: [Tenured: 25725K->25725K(1048576K), 0.8543338 secs] 25725K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8545040 secs
從日志看,和我們現(xiàn)場的狀況非常相似,heap空間充足,但是perm已經(jīng)到了32M,無法再進(jìn)一步分配空間,直接導(dǎo)致jvm頻繁做Full GC,控制臺也開始拋出OOM(Perm引起的回收都是full gc),這樣看基本我們判斷是Perm太小,導(dǎo)致無法加載classes導(dǎo)致的
和客戶溝通之后,我們本來打算進(jìn)一步驗證(在生產(chǎn)環(huán)節(jié)打開PrintGCDetail,獲取詳細(xì)的GC log),后面仔細(xì)檢查nohup.out,發(fā)現(xiàn)里面已經(jīng)拋出了 OutOfMemoryError:PermGen Space,至此我們確定是Perm設(shè)置不合理導(dǎo)致了本次事故,和客戶確認(rèn)之后,我們在啟動參數(shù)中加上了MaxPermSize
后面想到中間上了集群之后,eos加載了大量的jboss cache class,這也直接解釋了為什么這段時間OOM出現(xiàn)的頻率比之前更頻繁的原因
這里總結(jié)一下,希望對碰到類似問題的tx有借鑒意義,強(qiáng)烈建議用sun jdk 1.4.2的同學(xué)升級到>=1.4.2_12,便于對OOM問題的診斷,并加上GC log協(xié)助驗證。
這里再介紹一下JVM發(fā)生OOM的幾種情況:
1、java.lang.OutOfMemoryError: Java heap space
這是我們平常理解的OOM,是由于heap space確實沒有空間分配,這種一般是由于內(nèi)存泄漏導(dǎo)致,也有可能是heap space設(shè)置太小。需要具體分析
2、java.lang.OutOfMemoryError: PermGen space
jvm規(guī)范里面有定義一個method space,這里主要放classes和method list和一個string pool,string有一個intern方法,通過這個方法定義的string都放在這里(好像不常用),這里設(shè)置不太小會導(dǎo)致OOM,缺省64M,主要由于現(xiàn)在應(yīng)用依賴的第三方類越來越多,導(dǎo)致這類問題頻繁發(fā)生,需要引起重視
3、Requested array size exceeds VM limit
這種是由于申請的array size超出了heap space大小,比如在一個256M的heap space中申請一個512M的array,這種基本都是應(yīng)用bug導(dǎo)致
4、request <size> bytes for <reason>. Out of swap space?
這種是由于heap size設(shè)置相對于系統(tǒng)物理內(nèi)存太大,導(dǎo)致系統(tǒng)swap space不足,這種的解決辦法就是減小heap size大小
5、<reason> <stack trace> (Native method)
這種估計是最麻煩的了,也是最少碰到的,是由于jni或native method導(dǎo)致,如果自己沒有寫這類的東西,基本可以說是jdk問題
posted @ 2008-03-16 22:38 tacy lee 閱讀(2738) | 評論 (2) | 編輯 收藏
之前就準(zhǔn)備了一堆的片子,好好享受了一把,留下幾部有映象的吧:
強(qiáng)烈推薦型:
咱們自家的片子先推薦:《盲山》
看盲山,讓我想起Michael Moore,我一直認(rèn)為,嚴(yán)肅題材的電影本身就是電影存在的意義所在,我們需要用影像真實的記錄這個時代,我們需要這些“冷名人”,他們也許不是名利場的寵兒,但是他們一樣會有無數(shù)喜歡他們的人
《我在伊朗長大》
聽主人公瑪嘉娓娓道來,伊朗社會的變遷,依稀可以看到我們的影子,影片沒有去譴責(zé)或者反省或者什么高深的立意,只是要告訴你這個社會的樣子
《進(jìn)退維谷》
只要是Paul Haggis,都值得你關(guān)注,呵呵,反戰(zhàn)的片子,我感覺比之前的撞車有過之而無不及,不知為啥挺冷的,Tommy應(yīng)該提名最佳男演員,不過他好像評老無所依提名
《偷心》
老片子,看吧,不后悔,愛死這個精靈古怪的Natalie了,哈哈,真真假假誰又能分得清楚呢
《老無所依》
那個僵尸男實在太酷了,Tommy今年也挺火的,哈哈
隨便看看:
神探,喜歡記憶碎碎片,搏擊俱樂部這類片子的人可以看看,劉青云的表演我個人覺得一般,反正也就
美國黑幫(Denzel Washington新片,值得一看)
諜影重重3(這個還是比較經(jīng)典,今年馬特達(dá)蒙很火,整部片子非常緊湊,緊張刺激),
我的盛大同志婚禮(無厘頭Adam Sandler,去年的神奇遙控器記憶猶新),
一年到頭(騙了我一把眼淚)
C+偵探
贖罪(最近很火,看看吧)
哈哈,不記得了,還有一些,另外看了第一季反恐24,感覺一般
posted @ 2008-02-13 14:02 tacy lee 閱讀(257) | 評論 (0) | 編輯 收藏
posted @ 2008-02-01 13:26 tacy lee 閱讀(251) | 評論 (0) | 編輯 收藏
應(yīng)該來說,場面還是不錯的,國內(nèi)戰(zhàn)爭大片
太追求效果了,說實話,看過之后就忘了,在腦海里沒留下啥東西,雖然沒經(jīng)歷過戰(zhàn)爭,但是在解放戰(zhàn)爭年代的巷戰(zhàn)竟然打著手勢,為演戲而演戲,挺搞笑的,懷念黑鷹墜落中的那段伏擊戰(zhàn),谷子地站在空地里手舞足蹈那段看著太怪了,這是戰(zhàn)爭嗎,整個讓人感覺挺滑稽的,像一群新兵蛋子第一次上戰(zhàn)場,哭爹喊娘,太過啦馮導(dǎo)
耳朵被轟的夠嗆,后面開始打感情牌,賺點眼淚
馮導(dǎo)還是要加油啊,其實大家是喜歡看馮導(dǎo)還是葛優(yōu)呢,哈哈
posted @ 2008-01-04 16:05 tacy lee 閱讀(264) | 評論 (4) | 編輯 收藏
posted @ 2007-12-26 00:42 tacy lee 閱讀(1920) | 評論 (0) | 編輯 收藏
作者:tacy lee
由于大量開源框架的采用,Classes沖突的問題在我們的項目中越來越常見,下面寫了一個簡單的jsp,用來查找當(dāng)前使用類的位置:
<%@page contentType="text/html; charset=gb2312" %> <html> <head> <title>Class conflict</title> </head> <body> Example input: com.primeton.tp.web.driver.webdriver.PageDriver<br> <form action="<%=request.getRequestURI()%> " method="post"> <input type="text" name="className" size="50" ><br> <input type="submit" value="submit"> </form> <% String classLocation = null; String className =request.getParameter("className"); if ((className != null) && ((className = className.trim()).length() != 0)) { try{ classLocation = Class.forName(className).getProtectionDomain().getCodeSource().toString(); }catch(Throwable e){ log("error=" + e, e); } if (classLocation != null) { out.println("Class " + className + " found in <br>" + classLocation ); } else { out.println("Class '" + className + "' not found" ); } } %> </body> <html>
通過這個jsp頁面可以輸入需要查詢的類
-----------------------------------------------------------------------------------------------------------------------------------------------------
另外,websphere可以通過下面兩個方法來改變類的加載:
1、在"Applications" >"Enterprise Applications" >" yourear ">" Class Loading and File Update Detection"
修改:"Class loader mode" 為 "Parent Last",這樣應(yīng)用類可以覆蓋父裝載器的類
當(dāng)然但如果你混合使用了被覆蓋的類和沒有被覆蓋的類,則此操作有可能會導(dǎo)致 ClassCastException 或 LinkageErrors
2、在"Servers" > "Application servers" > "yourserver" > "Process Definition" > "Java Virtual Machine"
添加CLASSPATH,讓你的類先加載
posted @ 2007-12-21 18:05 tacy lee 閱讀(1343) | 評論 (0) | 編輯 收藏
posted @ 2007-12-20 17:04 tacy lee 閱讀(257) | 評論 (0) | 編輯 收藏
posted @ 2007-12-19 14:58 tacy lee 閱讀(305) | 評論 (0) | 編輯 收藏
作者:tacy lee
有用Websphere做過項目的人可能都知道,ibm一般都建議在Websphere前面加一個IHS來做webserver,據(jù)說這樣性能會提高30%左右,這樣說是否有道理呢,下面我做了一個簡單的測試來驗證:
測試環(huán)境:
硬件:
應(yīng)用服務(wù)器:Dell6600
壓力測試客戶端:自用筆記本(T2050 1.6G)
軟件:
系統(tǒng):CentOS 4.4
Websphere 6.0.2.17+IHS6.0.2.17(部署在同一臺機(jī)器上)
首先配置好Websphere和IHS,發(fā)布一個簡單的測試應(yīng)用,用loadrunner來測試一下不同的組合看看(錄制一個打開首頁就可以了),下面是我的測試數(shù)據(jù):
測試方法 | 每秒處理請求數(shù) | 響應(yīng)時間 | 服務(wù)器CPU |
直接請求Websphere | 4600/s | 0.013s | 28% |
通過IHS轉(zhuǎn)發(fā)請求 | 6800/s | 0.009s | 26% |
數(shù)據(jù)顯示,這還不是一點點提升,竟然快接近50%,把靜態(tài)資源放置到IHS中測試了一把,基本和通過IHS轉(zhuǎn)發(fā)差不多,稍微有些提升,不過放到IHS中可以方便Cache(Edge Server就包括了Caching Proxy component)
下面記錄一下如何放置靜態(tài)資源文件到IHS中:
1、打開Plugins中的plugin-cfg.xml,修改如下內(nèi)容:
<UriGroup Name="default_host_eos_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.jsp"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.do"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eosmgr/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis2/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eoshome_deploy/*"/> </UriGroup>
也可以通過修改WEB-INF下ibm-web-ext.xmi中的fileServingEnabled為false,然后重新生成plugin-cfg.xml,但是我試了一下好像不好用。
另外Websphere(fixpacks 5.1.1.17, 6.0.2.25 and 6.1.0.15)之后的版本給Webcontainer增加了一個自定義參數(shù)
com.ibm.ws.webcontainer.disallowAllFileServing
設(shè)定它為true產(chǎn)生同樣的效果(而且他會覆蓋ibm-web-ext.xmi中的設(shè)置)。
2、拷貝你的所有資源文件到IHS的Root Directory中
3、重啟IHS
posted @ 2007-12-13 14:19 tacy lee 閱讀(5248) | 評論 (7) | 編輯 收藏
作者:tacy lee
經(jīng)常,我們在啟動應(yīng)用的時候發(fā)現(xiàn)系統(tǒng)需要的端口被別的程序占用,如何知道誰占有了我們需要的端口,很多人都比較頭疼,下面就介紹一種非常簡單的方法,希望對大家有用
假如我們需要確定誰占用了我們的9050端口
1、Windows平臺
在windows命令行窗口下執(zhí)行:
C:\>netstat -aon|findstr "9050"
TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 2016
看到了嗎,端口被進(jìn)程號為2016的進(jìn)程占用,繼續(xù)執(zhí)行下面命令:
C:\>tasklist|findstr "2016"
tor.exe 2016 Console 0 16,064 K
很清楚吧,tor占用了你的端口
2、AIX
$netstat -Aan|grep 30542
f10000f303321b58 tcp4 0 0 *.30542 *.* LISTEN
$rmsock f10000f303321b58 tcpcb
The socket 0x3321800 is being held by proccess 692476 (db2sysc).
這個我就不解釋了
3、Linux
$netstat -pan|grep 2809 tcp 0 0 0.0.0.0:2809 0.0.0.0:* LISTEN 9493/java
posted @ 2007-12-12 17:01 tacy lee 閱讀(1516) | 評論 (10) | 編輯 收藏
作者:tacy lee
今天在配置confluence郵件功能的時候,啟動sendmail竟然需要很長時間,網(wǎng)上查了查,有很多人碰到類似問題,但是一般都是關(guān)掉sendmail服務(wù)或者關(guān)掉dns了事,咱們現(xiàn)在要用它,自然不能關(guān)掉了事,dns也不能關(guān),關(guān)了服務(wù)器沒法解析域名
毫無疑問,sendmail去做dns lookup,并且無法lookup到域名,在等待解析超時!
resolv里面也指定了nameserver,應(yīng)該能正常做dns解析了,既然他無法解析域名,自然這是個本地域名,難道是hosts里面的問題,查看了一下hosts文件:
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.1.28 rdosrv
好像也沒發(fā)現(xiàn)啥不對的,他在解析啥呢,看看log去,找到/var/log/maillog(也可能在messages),看到如下內(nèi)容:
Dec 11 14:25:01 rdosrv sendmail[22710]: starting daemon (8.13.8): SMTP+queueing@01:00:00 Dec 11 14:25:01 rdosrv sm-msp-queue[22717]: My unqualified host name (rdosrv) unknown; sleeping for retry Dec 11 14:28:08 rdosrv sendmail[22803]: My unqualified host name (rdosrv) unknown; sleeping for retry Dec 11 14:35:23 rdosrv sendmail[22944]: My unqualified host name (rdosrv) unknown; sleeping for retry Dec 11 14:35:57 rdosrv sendmail[22962]: My unqualified host name (rdosrv) unknown; sleeping for retry Dec 11 14:36:54 rdosrv sendmail[22979]: My unqualified host name (rdosrv) unknown; sleeping for retry
竟然是無法解析rdosrv,有點意思,直接去ping rdosrv自然是沒問題,突然想到好像FQDN里面規(guī)定域名必須用"."結(jié)尾,難道是hosts里面少了一個".",嘗試修改hosts文件:
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.1.28 rdosrv. rdosrv
啟動sendmail,刷一下就啟動了,呵呵
回頭想想,問題其實很簡單,但是在網(wǎng)上卻沒找到什么好的方案,說明都挺懶得,能繞都繞過去了.
posted @ 2007-12-11 15:58 tacy lee 閱讀(2547) | 評論 (4) | 編輯 收藏
作者:tacy lee
在應(yīng)用使用過程中,我們經(jīng)常會碰到應(yīng)用響應(yīng)時間很慢,甚至沒有響應(yīng),但是應(yīng)用服務(wù)器可能并不是很繁忙,cpu利用率也非常低,引起這種狀況的原因有很多種,比如環(huán)境問題,應(yīng)用資源泄漏,數(shù)據(jù)庫原因等等,本文主要是從一次應(yīng)用性能診斷過程來談?wù)勅绾瓮ㄟ^數(shù)據(jù)庫診斷應(yīng)用性能問題。
問題:
測試過程中發(fā)現(xiàn)應(yīng)用中某個跳轉(zhuǎn)頁面執(zhí)行時間比較長,系統(tǒng)壓力不大,cpu利用很低,該頁面需要從cache中取數(shù)據(jù),第一次的時候加載cache(從數(shù)據(jù)庫中查詢回數(shù)據(jù)并cache)。
診斷:
頁面邏輯比較簡單,我們先用loadrunner模擬并發(fā)測試一下這個頁面,然后再數(shù)據(jù)庫端捕獲sql執(zhí)行情況。
1、打開db2監(jiān)控開關(guān)
#db2 connect to eos
#db2 update monitor switches using statement on
#db2 reset monitor all
2、幾分鐘之后,我們收集sql統(tǒng)計快照
#db2 get snapshot for dynamic sql on eos > dysqlstatus.out
現(xiàn)在統(tǒng)計信息已經(jīng)存放在dysqlstatus.out中,你可以使用任意方便的文本處理工具查看,我一般用windows上的gvim來處理,打開dysqlstatus.out
Number of executions = 1
Number of compilations = 1
Worst preparation time (ms) = 2
Best preparation time (ms) = 2
Internal rows deleted = 0
Internal rows inserted = 0
Rows read = 2
Internal rows updated = 0
Rows written = 0
Statement sorts = 0
Statement sort overflows = 0
Total sort time = 0
Buffer pool data logical reads = Not Collected
Buffer pool data physical reads = Not Collected
Buffer pool temporary data logical reads = Not Collected
Buffer pool temporary data physical reads = Not Collected
Buffer pool index logical reads = Not Collected
Buffer pool index physical reads = Not Collected
Buffer pool temporary index logical reads = Not Collected
Buffer pool temporary index physical reads = Not Collected
Total execution time (sec.ms) = 0.000377
Total user cpu time (sec.ms) = 0.010000
Total system cpu time (sec.ms) = 0.000000
Statement text = select ACTIVITYDEFID,ACTIVITYINSTID from wfworkitem wherePROCESSINSTID=104199 and CURRENTSTATE = 4
......
簡單說一下vi中的處理
:g!/Total execution time/d
只保留文本中的sql執(zhí)行時間,我們要按照執(zhí)行時間來排序
通過vim的visual功能選擇執(zhí)行時間塊(等號后面的數(shù)字),然后排序
Total execution time (sec.ms) = 0.050590
Total execution time (sec.ms) = 0.000170
Total execution time (sec.ms) = 0.000247
Total execution time (sec.ms) = 0.000292
Total execution time (sec.ms) = 0.000474
Total execution time (sec.ms) = 0.000330
Total execution time (sec.ms) = 0.000348
Total execution time (sec.ms) = 0.000279
Total execution time (sec.ms) = 0.000385
Total execution time (sec.ms) = 0.000296
Total execution time (sec.ms) = 0.000261
Total execution time (sec.ms) = 0.000195
Total execution time (sec.ms) = 0.000226
Total execution time (sec.ms) = 0.000227
Total execution time (sec.ms) = 0.000193
......
:'<,'>!sort
排序后的結(jié)果(部分)
Total execution time (sec.ms) = 2.027776
Total execution time (sec.ms) = 2.203624
Total execution time (sec.ms) = 2.504677
Total execution time (sec.ms) = 2.951256
Total execution time (sec.ms) = 3.119875
Total execution time (sec.ms) = 3.303277
Total execution time (sec.ms) = 3.303517
Total execution time (sec.ms) = 4.017133
Total execution time (sec.ms) = 4.043329
Total execution time (sec.ms) = 4.252125
Total execution time (sec.ms) = 4.400952
Total execution time (sec.ms) = 4.606765
Total execution time (sec.ms) = 5.208087
Total execution time (sec.ms) = 5.778598
Total execution time (sec.ms) = 8.117470
Total execution time (sec.ms) = 9797.905136
可以看到最長時間的sql total執(zhí)行時間耗費了3797.905123s.
現(xiàn)在我們到dysqlstatus.out中去找這條語句
Number of executions = 4602
Number of compilations = 4294967295
Worst preparation time (ms) = 2
Best preparation time (ms) = 2
Internal rows deleted = 0
Internal rows inserted = 0
Rows read = 2963688
Internal rows updated = 0
Rows written = 0
Statement sorts = 0
Statement sort overflows = 0
Total sort time = 0
Buffer pool data logical reads = Not Collected
Buffer pool data physical reads = Not Collected
Buffer pool temporary data logical reads = Not Collected
Buffer pool temporary data physical reads = Not Collected
Buffer pool index logical reads = Not Collected
Buffer pool index physical reads = Not Collected
Buffer pool temporary index logical reads = Not Collected
Buffer pool temporary index physical reads = Not Collected
Total execution time (sec.ms) = 9797.905136
Total user cpu time (sec.ms) = 9.290000
Total system cpu time (sec.ms) = 1.230000
Statement text = select * from XXXX_T_CNFACTIVITYDEF
這條語句總共執(zhí)行了4602次,平均每次的執(zhí)行時間2S,而且這些數(shù)據(jù)應(yīng)該是被cache起來的 ;)
總結(jié):
上面的方法簡單總結(jié)了從數(shù)據(jù)庫層面對應(yīng)用的性能問題診斷,希望對大家有所幫助,對于數(shù)據(jù)庫快照診斷問題的思路對于任意數(shù)據(jù)庫通用
補(bǔ)充一個unix上腳本處理方式:
sqlsort.sh
awk 'BEGIN{RS="";FS="\n";ORS="\n"};/Statement text/{print $1, $21, $24}' $1 | awk '$5 > 0 {print "AvgTime:", $11/$5, "\t", $0}'| sort -n | head -n $2|awk '{print $0, "\n"}'
posted @ 2007-11-25 14:51 tacy lee 閱讀(642) | 評論 (0) | 編輯 收藏
作者:tacy lee
在應(yīng)用中,我們經(jīng)常會碰到sql執(zhí)行很慢,但是數(shù)據(jù)庫cpu和內(nèi)存使用率又不高的情況,類似的問題基本上由于鎖,排序等原因造成,本文主要描述如何去定位鎖等待問題,誰在鎖等待?等待誰持有的鎖?鎖在那個表?
一、測試準(zhǔn)備
1、先在session1執(zhí)行如下操作,創(chuàng)建測試表
#db2 connect to eos #export DB2OPTIONS=+C #db2 "create table tacy_test (a int not null primary key,b varchar(10))" #db2 "insert into tacy_test values(1,'a')" #db2 "insert into tacy_test values(2,'a')" #db2 "insert into tacy_test values(3,'a')" #db2 "insert into tacy_test values(4,'a')" #db2 commit
2、在session2執(zhí)行如下操作
#db2 connect to eos #export DB2OPTIONS=+C
二、產(chǎn)生一個lock wait
在session1做一個表更新:
#db2 "update tacy_test set b='b' where a=4"
#db2 "update tacy_test set b='c' where a=4"
進(jìn)程被掛起等待
三、定位鎖等待
1、先來看看應(yīng)用的情況:
#db2pd -db eos -applications Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:37:37 Applications: Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid 0x10140040 8 [000-00008] 1 8425 Lock-wait 80 2 66 1 *LOCAL.db2inst1.071124043739 0x100CE540 7 [000-00007] 1 8358 UOW-Waiting 0 0 80 2 *LOCAL.db2inst1.071124043708
可以看到有一個應(yīng)用的狀態(tài)處于Lock-wait
2、現(xiàn)在我們來看看應(yīng)用在等什么
#db2pd -db eos -locks showlock wait Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:42:56 Locks: Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse 0x2C8E0760 3 02001806078066020000000052 Row ..X W 2 1 0 0 0x0 TbspaceID 2 TableID 1560 RecordID 0x2668007
鎖的類型為Row(行鎖),X鎖(排他鎖),下面是我們最關(guān)心的鎖的位置
TbspaceID 2 TableID 1560 RecordID 0x2668007
其中TbspaceID為表空間ID,TableID為表的ID,RecordID代表具體位置,全部應(yīng)該是0x0266807,其中前面三個字節(jié)為page number,為0x02668,后面一個字節(jié)代表solt identifier,為0x073、找到相應(yīng)的表
#db2 "select tbspace,tabschema,tabname,tableid,tbspaceid from syscat.tables where tbspaceid=2 and tableid=1560"
TBSPACE TABSCHEMA TABNAME TABLEID TBSPACEID
------------ ----------- ---------- ------- ---------
USERSPACE1 DB2INST1 TACY_TEST 1560 2
1 record(s) selected.
4、根據(jù)RecordID找到鎖在哪行
db2提供了一個強(qiáng)大的數(shù)據(jù)分析工具db2dart,可以dump出相應(yīng)的page數(shù)據(jù)
#db2dart eos /dd /tsi 2 /oi 1560 /ps 157312p /np 1 /v y Warning: The database state is not consistent. Warning: Reorg rows MAY be due to the inconsistent state of the database. DB2DART Processing completed with warning(s)! Complete DB2DART report found in: /home/db2inst1/sqllib/db2dump/DART0000/EOS.RPT
其中tsi為表空間id(2),oi為表id(1560),ps為page number(0x0266807),需要轉(zhuǎn)換為十進(jìn)制,在結(jié)尾必須加p,np代表你要獲取的頁數(shù),v為是否詳細(xì)輸出
現(xiàn)在我們來看看EOS.RPT
______________________________________________________________________________ _______ DART _______ D a t a b a s e A n a l y s i s a n d R e p o r t i n g T o o l IBM DB2 6000 ______________________________________________________________________________ DART (V8.1.0) Report: 2007-11-24-20.59.51.355893 Database Name: EOS Report name: EOS.RPT Old report back-up: EOS.BAK Database Subdirectory: /opt/db2/db2inst1/NODE0000/SQL00001 Operational Mode: Database Inspection Only (INSPECT) ______________________________________________________________________________ ------------------------------------------------------------------------------ Action option: DD Table-object-ID: 1560; Tablespace-ID: 2; First-page: 157312p; Number-pages: 1; Verbose: y Warning: The database state is not consistent. Warning: Reorg rows MAY be due to the inconsistent state of the database. Connecting to Buffer Pool Services... Table object report phase start. Dump format is verbose. ______________________________________ Page 0 of object 1560 from table space 2. BPS Page Header: Page Data Offset = 48 Page Data Length = 4048 Page LSN = 0000 AE97 AE41 Object Page Number = 0 Pool Page Number = 157312 Object ID = 1560 Object Type = Data Object Data Page Header: Slot Count = 8 Total Free Space = 2784 Total Reserve Space = 0 Youngest Reserve Space = n/a Youngest TID = n/a Free Space Offset = 2799 Maximum Record Size = 23 Data Records: Slot 0: Offset Location = 3996 (xF9C) Record Length = 32 (x20) Record Type = Data Object Header Control Record Page count = 1 Object Creation LSN = 0000 AE97 800C Object State = x0000 UDI Since Runstats = 0 DART Field = x00000000 Slot 1: Offset Location = 2992 (xBB0) Record Length = 1004 (x3EC) Record Type = Free Space Control Record Free space entries: 0: 2884 (x0B44), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC) 4: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC) 8: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC) 省略。。。 492: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC) 496: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC) Slot 2: Offset Location = 2916 (xB64) Record Length = 76 (x4C) Record Type = Table Directory Record MetaIndex Root Page = 157377 Index Type = 2 Table Descriptor Pointer -- Page 157312 Slot 3 Max Insert Search = 0 Flags = x02000200 bit representation = 00000010 00000000 00000010 00000000 Check pending info: Constraint status = x00 Constraint RID = Page 0 Slot 0 last BID = x00000000 Slot 3: Offset Location = 2892 (xB4C) Record Length = 24 (x18) Record Type = Table Description Record Number of Columns = 2 Column 1: Type is Long Integer Length = 4 Prohibits NULLs Prohibits Default Fixed offset: 0 Column 2: Type is Fixed Length Character String Length = 10 Allows NULLs Prohibits Default Fixed offset: 4 Slot 4: Offset Location = 2869 (xB35) Record Length = 23 (x17) Record Type = Table Data Record (FIXEDVAR) Fixed part length value = 15 Column 1: Fixed offset: 0 Type is Long Integer Value = 1 Column 2: Fixed offset: 4 Type is Fixed Length Character String 61202020 20202020 2020 a Slot 5: Offset Location = 2846 (xB1E) Record Length = 23 (x17) Record Type = Table Data Record (FIXEDVAR) Fixed part length value = 15 Column 1: Fixed offset: 0 Type is Long Integer Value = 2 Column 2: Fixed offset: 4 Type is Fixed Length Character String 61202020 20202020 2020 a Slot 6: Offset Location = 2823 (xB07) Record Length = 23 (x17) Record Type = Table Data Record (FIXEDVAR) Fixed part length value = 15 Column 1: Fixed offset: 0 Type is Long Integer Value = 3 Column 2: Fixed offset: 4 Type is Fixed Length Character String 61202020 20202020 2020 a Slot 7: Offset Location = 2800 (xAF0) Record Length = 23 (x17) Record Type = Table Data Record (FIXEDVAR) Fixed part length value = 15 Column 1: Fixed offset: 0 Type is Long Integer Value = 4 Column 2: Fixed offset: 4 Type is Fixed Length Character String 61202020 20202020 2020 a Slots Summary: Total=8, In-use=8, Deleted=0. Table object report phase end. ______________________________________ DB2DART Processing completed with warning(s)! Warning(s) detected during processing. ______________________________________ Complete DB2DART report found in: /home/db2inst1/sqllib/db2dump/DART0000/EOS.RPT _______ D A R T P R O C E S S I N G C O M P L E T E _______
找到Solt 7 (0x07),ok,你現(xiàn)在可以清楚的知道應(yīng)用等待的Row為(4,a)
總結(jié)
通過上面的方法,我們簡單描述了一個db2鎖問題的定位方法,希望能給大家在分析和定位應(yīng)用性能問題的時候起到一定的幫助
posted @ 2007-11-24 21:18 tacy lee 閱讀(3064) | 評論 (2) | 編輯 收藏
一:基本介紹
在Loadrunner的使用中,對于Run-time Settings下的browser emulation設(shè)置是比較容易讓人產(chǎn)生困惑的地方。下面我們結(jié)合sniffer來具體看看每個選項的用途,以及對測試的影響。
Browser Emulation 圖
二:案例和工具
1. 測試案例:
打開網(wǎng)站首頁兩次,對比不同Browser Emulation設(shè)置下loadrunner的行為,腳本如下。
Action() { web_url("www.primeton.com", "URL=http://www.primeton.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t2.inf", "Mode=HTML", LAST); web_url("www.primeton.com", "URL=http://www.primeton.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t2.inf", "Mode=HTML", LAST); return 0; }
2. sniffer工具
開源工具:Wireshark(前身是ethereal)(www.wireshark.org)
三:測試過程
為了方便描述,我們約定用:
A代表Simulate browser cache
B代表Cache URLs requiring content(HTMLs)
C代表Check for newer versions of stored pages every visit to the page
D代表Download non-HTML resources
E代表Simulate a new user on each iteratioin
F代表Clear cache on each iteration
首先設(shè)置Run Logic中的iteration為2。讓Action運(yùn)行兩次,看看循環(huán)運(yùn)行腳本兩次,數(shù)據(jù)包和連接數(shù)的變化。
1. 去掉所有選項
結(jié)果:共獲取數(shù)據(jù)包95個,建立連接1個(紅色標(biāo)識),斷開連接1個(藍(lán)色標(biāo)識)
No. Time Source Destination Protocol Info 1 0.000000 192.168.1.61 203.81.29.137 TCP 13835 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 2 0.036053 203.81.29.137 192.168.1.61 TCP http > 13835 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 92 1.415887 192.168.1.61 203.81.29.137 TCP 13835 > http [FIN, ACK] Seq=817 Ack=71762 Win=257760 Len=0 94 1.449960 203.81.29.137 192.168.1.61 TCP http > 13835 [FIN, ACK] Seq=71762 Ack=818 Win=16464 Len=0
在這種情況下,數(shù)據(jù)包非常少(沒有選擇下載資源文件入css,js,gif等),而且你可以看到,打開4次首頁,只建立了一個tcp連接。
這時,你即使選擇A,發(fā)現(xiàn)數(shù)據(jù)包的數(shù)量量頁沒有變化,因為cache主要還是針對資源文件
2. 選擇E(F)
結(jié)果:共獲取數(shù)據(jù)包102個,建立連接2個(紅色標(biāo)識),斷開連接2個(藍(lán)色標(biāo)識)
No. Time Source Destination Protocol Info 1 0.000000 192.168.1.61 203.81.29.137 TCP 13886 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 2 0.037013 203.81.29.137 192.168.1.61 TCP http > 13886 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 48 0.618117 192.168.1.61 203.81.29.137 TCP 13886 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0 49 0.644106 192.168.1.61 203.81.29.137 TCP 13887 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 51 0.651919 203.81.29.137 192.168.1.61 TCP http > 13886 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0 53 0.676377 203.81.29.137 192.168.1.61 TCP http > 13887 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 99 1.310379 192.168.1.61 203.81.29.137 TCP 13887 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0 101 1.347949 203.81.29.137 192.168.1.61 TCP http > 13887 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
在這種情況下,數(shù)據(jù)包非常少(沒有選擇下載資源文件入css,js,gif等),對比第一種情況,你會發(fā)現(xiàn)它建立了兩個連接,這就是E的作用,它對于每次迭代都當(dāng)成一個新的用戶,需要重新建立連接。
3. 選擇DE(F)
結(jié)果:共獲取數(shù)據(jù)包1782個,建立連接6個(紅色標(biāo)識),斷開連接6個(藍(lán)色標(biāo)識)
No. Time Source Destination Protocol Info 1 0.000000 192.168.1.61 203.81.29.137 TCP 14016 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 2 0.037911 203.81.29.137 192.168.1.61 TCP http > 14016 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 6 0.107432 192.168.1.61 203.81.29.137 TCP 14017 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 9 0.141816 203.81.29.137 192.168.1.61 TCP http > 14017 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 426 3.334889 192.168.1.61 203.81.29.137 TCP 14017 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0 428 3.372253 203.81.29.137 192.168.1.61 TCP http > 14017 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0 448 4.395488 192.168.1.61 203.81.29.137 TCP 14020 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 457 4.439604 203.81.29.137 192.168.1.61 TCP http > 14020 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 859 7.593610 192.168.1.61 203.81.29.137 TCP 14016 > http [FIN, ACK] Seq=2849 Ack=377404 Win=257484 Len=0 870 7.659680 203.81.29.137 192.168.1.61 TCP http > 14016 [FIN, ACK] Seq=377404 Ack=2850 Win=15935 Len=0 888 8.511308 192.168.1.61 203.81.29.137 TCP 14020 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0 890 8.549451 203.81.29.137 192.168.1.61 TCP http > 14020 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0 892 8.566246 192.168.1.61 203.81.29.137 TCP 14022 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 893 8.601893 203.81.29.137 192.168.1.61 TCP http > 14022 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 899 8.702628 192.168.1.61 203.81.29.137 TCP 14023 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 904 8.741807 203.81.29.137 192.168.1.61 TCP http > 14023 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 1298 11.809456 192.168.1.61 203.81.29.137 TCP 14022 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0 1310 11.878665 203.81.29.137 192.168.1.61 TCP http > 14022 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0 1341 12.771707 192.168.1.61 203.81.29.137 TCP 14026 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 1348 12.813950 203.81.29.137 192.168.1.61 TCP http > 14026 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 1759 16.032952 192.168.1.61 203.81.29.137 TCP 14023 > http [FIN, ACK] Seq=3151 Ack=367918 Win=257484 Len=0 1761 16.068296 203.81.29.137 192.168.1.61 TCP http > 14023 [FIN, ACK] Seq=367918 Ack=3152 Win=17280 Len=0 1779 16.983042 192.168.1.61 203.81.29.137 TCP 14026 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0 1781 17.016836 203.81.29.137 192.168.1.61 TCP http > 14026 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0
在這種情況下,數(shù)據(jù)包的數(shù)量非常大,連接也很多,由于沒有cache功能,每次打開頁面都需要重新下載所有的資源文件。
4. 選擇ADE
結(jié)果:共獲取數(shù)據(jù)包525個,建立連接3個,斷開連接3個(不再標(biāo)識了,syn即為連接請求,fin即為斷開請求)
No. Time Source Destination Protocol Info 1 0.000000 192.168.1.61 203.81.29.137 TCP 14189 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 2 0.033657 203.81.29.137 192.168.1.61 TCP http > 14189 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 6 0.100636 192.168.1.61 203.81.29.137 TCP 14190 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 9 0.133703 203.81.29.137 192.168.1.61 TCP http > 14190 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 429 3.383748 192.168.1.61 203.81.29.137 TCP 14190 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0 431 3.418556 203.81.29.137 192.168.1.61 TCP http > 14190 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0 471 4.352071 192.168.1.61 203.81.29.137 TCP 14189 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0 472 4.380312 192.168.1.61 203.81.29.137 TCP 14192 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 474 4.389778 203.81.29.137 192.168.1.61 TCP http > 14189 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0 476 4.413220 203.81.29.137 192.168.1.61 TCP http > 14192 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 522 5.078068 192.168.1.61 203.81.29.137 TCP 14192 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0 524 5.115099 203.81.29.137 192.168.1.61 TCP http > 14192 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
在這種情況下,cache發(fā)揮作用,數(shù)據(jù)包對比第三種情況大大減少,幾乎等于打開一次首頁的數(shù)據(jù)量(449個數(shù)據(jù)包),只有第一次打開頁面需要完整下載頁面(包括資源文件),后面的三次打開頁面都只要下載HTML頁面(不包括資源文件)。
5. 選擇ADEF
選擇F之后我們看看結(jié)果:共獲取數(shù)據(jù)包942個,建立連接4個,斷開連接4個
No. Time Source Destination Protocol Info 1 0.000000 192.168.1.61 203.81.29.137 TCP 14292 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 2 0.034524 203.81.29.137 192.168.1.61 TCP http > 14292 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 6 0.102314 192.168.1.61 203.81.29.137 TCP 14294 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 9 0.139752 203.81.29.137 192.168.1.61 TCP http > 14294 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 426 3.791111 192.168.1.61 203.81.29.137 TCP 14294 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0 428 3.824970 203.81.29.137 192.168.1.61 TCP http > 14294 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0 468 6.213276 192.168.1.61 203.81.29.137 TCP 14292 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0 469 6.244052 192.168.1.61 203.81.29.137 TCP 14297 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 471 6.249564 203.81.29.137 192.168.1.61 TCP http > 14292 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0 473 6.279647 203.81.29.137 192.168.1.61 TCP http > 14297 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 479 6.374967 192.168.1.61 203.81.29.137 TCP 14298 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2 484 6.419597 203.81.29.137 192.168.1.61 TCP http > 14298 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0 897 9.858493 192.168.1.61 203.81.29.137 TCP 14297 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0 899 9.895188 203.81.29.137 192.168.1.61 TCP http > 14297 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0 939 12.840029 192.168.1.61 203.81.29.137 TCP 14298 > http [FIN, ACK] Seq=1806 Ack=226090 Win=257760 Len=0 941 12.876120 203.81.29.137 192.168.1.61 TCP http > 14298 [FIN, ACK] Seq=226090 Ack=1807 Win=17076 Len=0
在這種情況下,由于選擇了F,在迭代的時候清除了cache,所以每次迭代都需要重新下載資源文件。數(shù)據(jù)包差不多等于第三種情況的一半,約等于打開兩次首頁的數(shù)據(jù)量(449×2個數(shù)據(jù)包)。
6. 關(guān)于BC選項
C的解釋(Check for newer versions of stored pages every visit to the page)
C比較容易理解,類似IE設(shè)置中的每次檢查,如果不設(shè)置C,LR對于已經(jīng)cache的文件就不會重新向服務(wù)器請求,如果選擇C,你就可以在數(shù)據(jù)包中發(fā)現(xiàn)很多304信息。
B的解釋(Cache URLs requiring content(HTMLs))
LR對于資源文件的cache并不會真正cache在內(nèi)存中或者在磁盤上,這個選項表示:對于一些需要用到的關(guān)聯(lián),校驗,頁面解析內(nèi)容真正cache在內(nèi)存中,減少客戶端的重復(fù)工作。
當(dāng)然如果你想把GIF也cache到內(nèi)存中,你可以在Advanced中設(shè)置,選擇Specify URL requiring content in addition to HTML pages,加入條目image/gif,并勾選。當(dāng)Vuser運(yùn)行的時候,你可以對比一下mmdrv.exe進(jìn)程的內(nèi)存消耗(內(nèi)存占用會更多)。
四: 結(jié)論
通過上面的測試分析,我們大概知道了每個選項的真正含義,你需要根據(jù)你的測試目的來選擇合適的設(shè)置:
1、 對于一個具體的應(yīng)用測試,對于前端Web Server不可忽略,缺省設(shè)置非常合適,不需要調(diào)整(有時候需要考慮把C選上)
注意:很多人在錄制腳本的時候,習(xí)慣把登入操作放到vuser_init中,這時候缺省設(shè)置可能會拋錯,建議把這類的操作都放入到action中
2、 如果你更關(guān)注后端應(yīng)用服務(wù)器的性能或者說做一些架構(gòu)的驗證分析,那你缺省設(shè)置對于你來說就不合適了,你需要選擇取消所有的設(shè)置項。
當(dāng)然你也可以根據(jù)自己的具體情況做不同調(diào)整,但是一定要真正理解這些選項的具體含義才能做到不犯錯誤
posted @ 2007-11-06 00:19 tacy lee 閱讀(1356) | 評論 (0) | 編輯 收藏
編譯的時候出現(xiàn)java拋如下異常:
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:419)
at java.nio.HeapCharBuffer.put(HeapCharBuffer.java:145)
at com.sun.tools.javac.parser.Scanner.decode(Scanner.java:405)
at com.sun.tools.javac.parser.Scanner.<init>(Scanner.java:304)
at com.sun.tools.javac.parser.Scanner.<init>(Scanner.java:238)
at com.sun.tools.javac.parser.Scanner$Factory.newScanner(Scanner.java:72)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:254)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:281)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:399)
at com.sun.tools.javac.main.Main.compile(Main.java:592)
at com.sun.tools.javac.main.Main.compile(Main.java:544)
at com.sun.tools.javac.Main.compile(Main.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:55)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:936)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.startAnt(BizletProcessor.java:327)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.prepareclass(BizletProcessor.java:419)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.init(BizletProcessor.java:374)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.build(BizletProcessor.java:130)
at com.primeton.studio.compile.frame.ProjectProcessor.buildBizlets(ProjectProcessor.java:161)
at com.primeton.studio.compile.frame.ProjectProcessor.build(ProjectProcessor.java:115)
at com.primeton.studio.compile.frame.SimpleBuilder.build(SimpleBuilder.java:195)
at com.primeton.studio.compile.frame.SimpleBuilder.build(SimpleBuilder.java:182)
at com.primeton.studio.compile.frame.SimpleBuilder.main(SimpleBuilder.java:265)
查了一下,估計是java采用gbk字符集(缺省windows的中文字符集),導(dǎo)致stack區(qū)溢出(明顯沒對國際化測試不足嘛)
解決問題的方法就是修改系統(tǒng)的缺省區(qū)域設(shè)置為English既可。
posted @ 2007-11-05 22:37 tacy lee 閱讀(1224) | 評論 (0) | 編輯 收藏
故障現(xiàn)象:
測試一段時間后應(yīng)用無響應(yīng),連接池不能放大,jvm crash,日志報對象分配失敗
問題診斷:
第一個階段是websphere問題
到現(xiàn)場之后,回放腳本測試幾分鐘,應(yīng)用開始無法響應(yīng),后臺也沒有異常,update jdk之后,系統(tǒng)能正常響應(yīng)了,但是發(fā)現(xiàn)新的問題,db2連接池始終無法放大,最大只能到30,而且系統(tǒng)也會拋OOM,導(dǎo)致系統(tǒng)異常推出,從系統(tǒng)日志看,是因為應(yīng)用中的大對象分配導(dǎo)致的(2M大小)
期間,關(guān)于連接池?zé)o法放大問題想了很多辦法,包括修改db2 maxappls,maxagents這些參數(shù),更新數(shù)據(jù)庫驅(qū)動,而且確定不是db2的問題(在創(chuàng)建30之后,我們依然可以通過其他方式連接到db2,說明db2的連接限制確實放大了),當(dāng)然我們productdatasource這個池子大小我已經(jīng)放大到100了。
中間還發(fā)現(xiàn)測試腳本沒有正常啟動流程,排查后發(fā)現(xiàn)是loadrunner的問題,用我機(jī)器上的lr錄制正常(錯誤代碼提示是字段長度限制,莫名其妙)。
關(guān)于jvm crach我們也調(diào)整了heap設(shè)置:-xms256m,-xmx1536m
但是問題依然存在。后面我們重新安裝了應(yīng)用,所有的設(shè)置采用缺省配置,沒有打任何補(bǔ)丁,系統(tǒng)這個時候竟然可以正常跑了,只是響應(yīng)很慢,而且時間曲線一直往上拋(測試一段時間系統(tǒng)無響應(yīng))
查了一下配置,發(fā)現(xiàn)productdatasource的缺省設(shè)置竟然就是30,這個時候基本判斷是之前的websphere的設(shè)置修改沒有生效
重新修改jvm和連接池配置,這時候系統(tǒng)正常,數(shù)據(jù)連接也達(dá)到83個,然后開始測試大并發(fā)量
階段二就是調(diào)整數(shù)據(jù)庫配置
1、第一個是db2 default buffer pool,缺省配置buffer才4m,這個一定要注意修改
2、第二個是db2的lock數(shù)量,在缺省基礎(chǔ)上好像放大了100倍
3、sort heap,排序區(qū)(防止排序溢出)
這些調(diào)整都要通過db2的狀態(tài)來調(diào)整,可以通過get snapshot指令來獲得數(shù)據(jù)庫狀態(tài),buffer不夠會出現(xiàn)大量的邏輯讀,lock不夠會拋lock溢出(會導(dǎo)致鎖升級),sort heap不夠會提示排序溢出(這時候排序會在硬盤做)
回頭看看這次支持:
1、websphere配置修改不生效,我后面仔細(xì)想了想,這個websphere很多公司用可能大家都亂改了一通,另一問題是我們的使用習(xí)慣,websphere強(qiáng)烈不建議用kill直接殺進(jìn)程方式停服務(wù)器,websphere不但是一個java進(jìn)程,還有很多的附屬進(jìn)程,直接kill也很容易導(dǎo)致websphere不正常
2、jvm crach問題,這個我建議大家看看這篇文檔http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=fragmentation
&uid=swg21176363&loc=en_US&cs=utf-8&lang=en
如何去定位jvm問題,首先看nativerr.log日志,如果出現(xiàn)OOM,這里會有記錄,當(dāng)發(fā)現(xiàn)OOM的時候,可以打開jvm的verbosegc,分析verbosegc和jvm dump file,上面文檔里提到一個很重要的東西就是pinned對象,這也是ibm為啥不建議設(shè)置ms=mx的原因。
posted @ 2007-10-30 13:09 tacy lee 閱讀(374) | 評論 (0) | 編輯 收藏
先建立一個監(jiān)控器
db2 "create event monitor SQLCOST for statements write to file '/home/db2inst1'"
再設(shè)置事務(wù)狀態(tài)為打開
db2 "set event monitor SQLCOST state=1"
注:1為打開,0為關(guān)閉,收集數(shù)據(jù)之后,記得關(guān)閉你的監(jiān)控器,否則。。。
跑你的測試后,在你的/home/db2inst1目錄下會生成一些evm文件
用下面指令獲取診斷信息:
db2evmon -db eos51 -evm SQLCOST>sqlcost1.txt
完成之后刪除你的監(jiān)控器
db2 "drop event monitor SQLCOST"
生成的采樣例子,從下面的例子中,你可以清除的看到SQL執(zhí)行的時間,CPU消耗情況,排序是否溢出,BufferPool的使用情況,根據(jù)這些信息,SQL的執(zhí)行效率一目了然:
26) Statement Event ...
Appl Handle: 336
Appl Id: C0A80421.O905.0ABDA5065446
Appl Seq number: 0657
Record is the result of a flush: FALSE
-------------------------------------------
Type : Dynamic
Operation: Execute
Section : 7
Creator : NULLID
Package : SYSSN300
Consistency Token : SYSLVL01
Package Version ID :
Cursor : SQL_CURSN300C7
Cursor was blocking: FALSE
Text : update WFProcessInst set relateData=? where processInstID= ?
-------------------------------------------
Start Time: 04/25/2007 14:57:19.402248
Stop Time: 04/25/2007 14:57:19.409622
Exec Time: 0.007374 seconds
Number of Agents created: 1
User CPU: 0.000000 seconds
System CPU: 0.000000 seconds [licl1]
Fetch Count: 0
Total sort time: 0
Sort overflows: 0 [licl2]
Rows read: 1
Rows written: 1
Internal rows deleted: 0
Internal rows updated: 0
Internal rows inserted: 0
Bufferpool data logical reads: 9
Bufferpool data physical reads: 0
Bufferpool temporary data logical reads: 0
Bufferpool temporary data physical reads: 0
Bufferpool index logical reads: 3
Bufferpool index physical reads: 0
Bufferpool temporary index logical reads: 0
Bufferpool temporary index physical reads: 0 [licl3]
SQLCA:
sqlcode: 0
sqlstate: 00000
[licl1]SQL執(zhí)行時間和CPU消耗情況
[licl2]SQL的排序情況,可以看到這個SQL沒有排序,當(dāng)然也沒有排序溢出
[licl3]Bufferpool的使用情況,邏輯讀和物理讀的對比
posted @ 2007-10-30 12:59 tacy lee 閱讀(553) | 評論 (0) | 編輯 收藏