2007年10月23日 #

          語錄一

          某天,停車,圖方便隨便停在路邊,抱怨了兩句,ld隨即頂回一句:“只要有邊就能停”

          posted @ 2008-11-18 23:32 tacy lee 閱讀(246) | 評論 (0)編輯 收藏

          oracle 的lob & long

          一直認(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)廢棄它了。

          testClobLong.java

          posted @ 2008-06-24 01:18 tacy lee 閱讀(456) | 評論 (0)編輯 收藏

          殺掉服務(wù)器上的遠(yuǎn)程桌面連接

          用遠(yuǎn)程桌面連接登入服務(wù)器的時候,你可能會經(jīng)常碰到下面的情況:

          mstsc-exceed-456x114

           

          也就是說,服務(wù)器的連接數(shù)已經(jīng)滿了,很多時候,可能是別人異常斷開連接,導(dǎo)致連接沒有釋放,一般這時候你需要去機房登入服務(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 (這樣才能保證運行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-18 19:45 tacy lee 閱讀(249) | 評論 (0)編輯 收藏

          地震

          最近一段時間特別忙,以至于發(fā)生地震這么大的事情都沒注意到,首都人民不斷告訴我被震了也沒當(dāng)回事,昨晚回家打開電視,新聞頻道,懵了,坐下來一直看,到晚上2點,滿目蒼痍,真為處于震中的人揪心,中間鼻子酸了N次,也憤怒了N次(那些惡心人的地方官,難道就不能說點實際的東西嗎?)

          1、政府反映非常迅速
          2、子弟兵真好
          2、有一個好總理
          3、地方政府不作為,官話套話(被采訪的那個什么何彪,真想抽丫的)
          4、為什么總是學(xué)校?處于地址多發(fā)地帶的學(xué)校和其他公共設(shè)施為什么都是豆腐渣

          為所有受難的人祈禱!為我們飽受磨難的祖國祈禱!

          公司員工捐款20W,盡點綿力

          posted @ 2008-05-14 10:17 tacy lee 閱讀(243) | 評論 (0)編輯 收藏

          ibm jdk 1.5缺省用的gc策略性能很差

               摘要: 這幾天測試一個引擎的性能,用一個單表查詢的case,測試出來的結(jié)果是210tps,cpu也正常,在85%左右,也沒懷疑。

          后面再重新測試的時候,加上了gc log,用gc分析工具分析了一下gc的吞吐量,發(fā)現(xiàn)吞吐量奇低,竟然只有77%左右,很是奇怪,看了一下gc日志,所有都是global gc, 懷疑gc策略有問題,查了一下資料,參考了下面一篇文章:  閱讀全文

          posted @ 2008-04-14 20:38 tacy lee 閱讀(4456) | 評論 (2)編輯 收藏

          Sybase 鎖模式

          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:強烈建議用這個鎖模式,對于oltp應(yīng)用,如果用前兩種鎖模式會導(dǎo)致頻繁死鎖

          另外,DataPages和DataRows對于index pages的控制采用latch方式,一種輕量級的鎖機制(熟悉oracle會比較清楚)

          對于Sybase ASE來說,鎖是非常寶貴的資源,不要長時間持有鎖,所以一般我們在寫應(yīng)用的時候盡量減少長事務(wù)

           

          另:Sybase ASE缺省的事務(wù)隔離級別:Read Committed

          posted @ 2008-04-01 10:50 tacy lee 閱讀(926) | 評論 (0)編輯 收藏

          并發(fā)是啥

          一個用戶點擊就是一個用戶請求,一個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 閱讀(292) | 評論 (0)編輯 收藏

          工作日志-OOM事件

          某項目,年前開始報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溢出,強制設(shè)置max perm大小為32M,并對GC進行了監(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,無法再進一步分配空間,直接導(dǎo)致jvm頻繁做Full GC,控制臺也開始拋出OOM(Perm引起的回收都是full gc),這樣看基本我們判斷是Perm太小,導(dǎo)致無法加載classes導(dǎo)致的

          和客戶溝通之后,我們本來打算進一步驗證(在生產(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有借鑒意義,強烈建議用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)備了一堆的片子,好好享受了一把,留下幾部有映象的吧:

           

          強烈推薦型

          咱們自家的片子先推薦:《盲山》

          看盲山,讓我想起Michael Moore,我一直認(rèn)為,嚴(yán)肅題材的電影本身就是電影存在的意義所在,我們需要用影像真實的記錄這個時代,我們需要這些“冷名人”,他們也許不是名利場的寵兒,但是他們一樣會有無數(shù)喜歡他們的人

          《我在伊朗長大》

          聽主人公瑪嘉娓娓道來,伊朗社會的變遷,依稀可以看到我們的影子,影片沒有去譴責(zé)或者反省或者什么高深的立意,只是要告訴你這個社會的樣子

          《進退維谷》

          只要是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)編輯 收藏

          公司同事拍的mv 歡迎捧場!

          http://www.tudou.com/programs/view/yKJB_VzHXYU/

          突然覺得,這一年收獲很多,感觸很多,需要仔細(xì)總結(jié)總結(jié)

          posted @ 2008-02-01 13:26 tacy lee 閱讀(251) | 評論 (0)編輯 收藏

          集結(jié)號

          應(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)編輯 收藏

          關(guān)于oracle中的timestamp和date類型

          之前一直認(rèn)為類似:where timestamp>date 這種子句是不走索引的

          下面簡單做一個驗證:

          c:>sqlplus / as sysdba
          sys@EOS >create table test as select table_name,to_timestamp(last_analyzed) date_test from dba_tables;

          表已創(chuàng)建。

          sys@EOS> create index idx_test_date on test (date_test);

          索引已創(chuàng)建。

          sys@EOS> desc test
           名稱                                                  是否為空? 類型
           ----------------------------------------------------- -------- ----------------
          --------------------
           TABLE_NAME                                            NOT NULL VARCHAR2(30)
           DATE_TEST                                                      TIMESTAMP(0)

          sys@EOS> select date_test from test where date_test > TO_DATE('2007-11-5 00:00:00','yyyy-MM-dd HH24:mi:ss');

          執(zhí)行計劃
          ----------------------------------------------------------
          Plan hash value: 944171586

          -------------------------------------------------------------------------------- --
          | Id  | Operation        | Name          | Rows  | Bytes | Cost (%CPU)| Time |
          -------------------------------------------------------------------------------- --
          |   0 | SELECT STATEMENT |               |     1 |    22 |     1   (0)| 00:00:01 |
          |*  1 |  INDEX RANGE SCAN| IDX_TEST_DATE |     1 |    22 |     1   (0)| 00:00:01 |
          -------------------------------------------------------------------------------- --

          Predicate Information (identified by operation id):
          ---------------------------------------------------

             1 - access("DATE_TEST">TIMESTAMP'2007-11-05 00:00:00')

          Note
          -----
             - dynamic sampling used for this statement


          統(tǒng)計信息
          ----------------------------------------------------------
                    7  recursive calls
                    0  db block gets
                   18  consistent gets
                    0  physical reads
                    0  redo size
                  280  bytes sent via SQL*Net to client
                  374  bytes received via SQL*Net from client
                    1  SQL*Net roundtrips to/from client
                    0  sorts (memory)
                    0  sorts (disk)
                    0  rows processed

          從上面可以清楚看到,timestamp>date情況下,走索引

          糾正我之前的認(rèn)識。

          另外再補充一下,date這個數(shù)據(jù)類型一般情況下很少用,建議產(chǎn)品里面所有的date數(shù)據(jù)類型全部改為timestamp

          posted @ 2007-12-26 00:42 tacy lee 閱讀(1920) | 評論 (0)編輯 收藏

          Websphere Classes沖突診斷

          作者: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)編輯 收藏

          google提供的翻譯機器人

          如果你使用gtalk,你可以使用google最近提供的翻譯機器人幫你翻譯

          只需要添加如下兩個機器人帳號到你的gtalk好友列表中:

          en2zh@bot.talk.google.com
          zh2en@bot.talk.google.com

          嘿嘿,你就可以讓他們幫你翻譯啦!

          google另外提供很多其他語言的機器人,有興趣的可以去了解一下


          posted @ 2007-12-20 17:04 tacy lee 閱讀(257) | 評論 (0)編輯 收藏

          firefox 3 beta 2釋放出來了

          官網(wǎng)已經(jīng)發(fā)布消息,好像原定應(yīng)該是21號發(fā)布嘛!

          具體看這里

          -----------------------------------------------------------------------------------
          update:

          已經(jīng)成功把自己的firefox升級到3,升級過程中,用的幾個插件手動調(diào)了一下版本限制,其中g(shù)oogle toolbar和yahoo的delicious不行,刪除之,變通方案:

          1、google toolbar我平時主要用來屏幕取詞,用backword替代
          2、yahoo的delicious用老版本替代(delicious沒被收購時發(fā)布的那個)

          用下來感覺速度確實快了很多,內(nèi)存占用也少了,原來動不動就給我奔200M,現(xiàn)在穩(wěn)定在90M左右,經(jīng)常訪問的一些網(wǎng)站都顯示正常。

          當(dāng)然這里不是鼓勵大家升級,如果你平時用到一些大塊頭的插件,那最好等他們升級

          列一下我用到的幾個插件:

          Adblock Plus:廣告屏蔽,這個不用多說了
          backword:屏幕取詞,主要是咱們英文太爛,看英文網(wǎng)站需要
          del.icio.us:美味書簽,換成了delicious沒被yahoo收購時開發(fā)的,少了側(cè)邊欄查找,唯一遺憾
          DictionarySearch:通過thefreedictionary查單詞(英英),強烈推薦
          FlashGot:下載管理器
          Tab Control:沒用那個龐大無比的Tab Mix Plus,這個很小,只是實現(xiàn)新打開的tab在當(dāng)前tab左邊,不要給我跑到最后去
          Torbutton:洋蔥頭,翻墻用的
          Vimperator:這個一般人估計不會用,只推薦給vi老手

          posted @ 2007-12-19 14:58 tacy lee 閱讀(305) | 評論 (0)編輯 收藏

          Websphere到底是否需要配置IHS

          作者: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(部署在同一臺機器上)

          首先配置好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

          del.icio.us Tags: ,,,

          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 
          
          


          看到了嗎,端口被進程號為2016的進程占用,繼續(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 
          del.icio.us Tags: ,,

          posted @ 2007-12-12 17:01 tacy lee 閱讀(1516) | 評論 (10)編輯 收藏

          unix啟動過程中sendmail長時間等待問題解決

          作者: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)上卻沒找到什么好的方案,說明都挺懶得,能繞都繞過去了.

          del.icio.us Tags: ,,

          posted @ 2007-12-11 15:58 tacy lee 閱讀(2547) | 評論 (4)編輯 收藏

          db2診斷系列之---捕獲sql執(zhí)行情況

          作者: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 where

          PROCESSINSTID=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ù)庫通用

           

          補充一個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"}'
           
          使用:#sqlsort.sh dysqlstate.out 10(顯示Top ten)
           
          del.icio.us Tags: ,,,

          posted @ 2007-11-25 14:51 tacy lee 閱讀(642) | 評論 (0)編輯 收藏

          db2診斷系列之---定位鎖等待問題

          作者: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"
          sql執(zhí)行成功
          在session2做同樣更新操作:
          #db2 "update tacy_test set b='c' where a=4"

          進程被掛起等待

          三、定位鎖等待

          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,為0x07

          3、找到相應(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提供了一個強大的數(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)換為十進制,在結(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)用性能問題的時候起到一定的幫助

          del.icio.us Tags: ,,,

          posted @ 2007-11-24 21:18 tacy lee 閱讀(3064) | 評論 (2)編輯 收藏

          深入理解Loadrunner中的Browser Emulation

          作者:tacy lee

          一:基本介紹

          在Loadrunner的使用中,對于Run-time Settings下的browser emulation設(shè)置是比較容易讓人產(chǎn)生困惑的地方。下面我們結(jié)合sniffer來具體看看每個選項的用途,以及對測試的影響。

          clip_image002

                                                         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運行兩次,看看循環(huá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運行的時候,你可以對比一下mmdrv.exe進程的內(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)整,但是一定要真正理解這些選項的具體含義才能做到不犯錯誤

          del.icio.us Tags: , ,

          posted @ 2007-11-06 00:19 tacy lee 閱讀(1356) | 評論 (0)編輯 收藏

          java 編譯異常解決一則

          編譯的時候出現(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既可。

          del.icio.us Tags: , , ,

          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大?。?/p>

          期間,關(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的問題,用我機器上的lr錄制正常(錯誤代碼提示是字段長度限制,莫名其妙)。

          關(guān)于jvm crach我們也調(diào)整了heap設(shè)置:-xms256m,-xmx1536m

          但是問題依然存在。后面我們重新安裝了應(yīng)用,所有的設(shè)置采用缺省配置,沒有打任何補丁,系統(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強烈不建議用kill直接殺進程方式停服務(wù)器,websphere不但是一個java進程,還有很多的附屬進程,直接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)編輯 收藏

          捕獲DB2 sql的執(zhí)行快照

          先建立一個監(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

          Sorts: 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的使用情況,邏輯讀和物理讀的對比

          del.icio.us Tags: , ,

          posted @ 2007-10-30 12:59 tacy lee 閱讀(553) | 評論 (0)編輯 收藏

          Loadrunner Analysis之Web Page Diagnostics

          作者:tacy lee

          簡單介紹一下Loadrunner Analysis中的Web Page Diagnostics模塊的使用,很多人對于測試之后的結(jié)果數(shù)據(jù)分析摸不著頭腦,其實loadrunner Analysis給你提供了很好的文檔,大家沒事可以多翻翻,多翻幾遍對于性能測試你就入門了 ;)

          Web Page Diagnostics (以下簡稱WPD),這是LR Analysis中非常重要的一塊,搞清楚這部分的內(nèi)容會讓你少走很多彎路,很多環(huán)境問題都可以通過它來定位,比如客戶端,網(wǎng)絡(luò)。通過它可以你可以比較好的來定位是環(huán)境的問題還是應(yīng)用本身的問題,當(dāng)然更重要的是Web頁面本身的問題。

          WPD包括下面幾個圖表:

          Web Page Diagnostics     這是張總圖,包括下面幾張Over Time圖的內(nèi)容

          Page Component Breakdown     頁面中每個元素的平均響應(yīng)時間占整個頁面響應(yīng)時間的百分比

          Page Component Breakdown(Over Time)     在整個測試過程中,任意一秒內(nèi)頁面中每個元素的響應(yīng)時間(例如在runtime中設(shè)置了browser cache,頁面中的資源文件就只會在第一次下載,后面的頁面響應(yīng)時間也就不包括這些元素的時間,這在Page Component Breakdown中是看不出來的,因為Page Component Breakdown是整個測試期間內(nèi)的平均時間。當(dāng)然,是否啟用了cache,通過over time圖就能看出來)

          Page Download Time Breakdown    頁面中每個元素的響應(yīng)時間分割圖,響應(yīng)時間被分割為以下幾個部分:DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error

          Page Download Time Breakdown(Over Time)      在整個測試過程中,任意一秒內(nèi)頁面中每個元素的響應(yīng)時間分割圖

          Time to First Buffer Breakdown      First Buffer Time時間分割為Network Time和Server Time,客戶端http請求發(fā)送到接收到服務(wù)器端的應(yīng)答包(ACK)為Network Time,從接收到ACK到完成First Buffer接受為Server Time

          Time to First Buffer Breakdown(Over Time)      基本同上,任意一秒內(nèi)的

          Downloaded Component Size(KB)      頁面中每個元素的大?。↘B)

          介紹了這么多,具體如何分析呢?

          首先打開Web Page Diagnostics圖,來看看下面一個例子Download Time圖:

          Web-Page-Diagnostics-DownloadTime

          上圖存在兩個問題:

          1、receive時間很長

          這個一般是網(wǎng)絡(luò)問題,當(dāng)然如果你確認(rèn)網(wǎng)絡(luò)不存在問題,那么你就要看看是不是客戶端的問題(客戶端也可能會造成Receive過長,這個千萬要注意)

          2、頁面問題

          頁面上包括了非常多的圖片,而且圖片似乎都沒有優(yōu)化,最大的竟然有163K,記下來,這可是罪證哦 ;)

          很多時候,你可以根據(jù)DNS,Connection,Receive來看出是否存在網(wǎng)絡(luò)問題,根據(jù)Client來判斷是否存在客戶端問題。

          看看,挺簡單的吧! ^_^

          換個圖看看,Page Component Breakdown(Over Time)

          Web-Page-Diagnostics-PCB

          很清楚吧,頁面元素都被cache了,說明場景啟用了browser cache,頁面的響應(yīng)時間只包括紅線和藍(lán)線。

          Time to First Buffer Breakdown(Over Time)  ,圖就不貼了,這個圖非常重要,也最復(fù)雜,這里的值不絕對,當(dāng)網(wǎng)絡(luò)狀況不好的時候,server time很可能包括網(wǎng)絡(luò)時間,因為很多頁面元素比較?。ㄐ∮?k的樣子),在First Buffer就完成傳輸,所以一定要注意分析。

          就嘮叨到這里吧,歡迎拍磚

          del.icio.us Tags: , ,

          posted @ 2007-10-23 19:04 tacy lee 閱讀(2271) | 評論 (1)編輯 收藏

          主站蜘蛛池模板: 汝阳县| 达州市| 启东市| 嘉鱼县| 威信县| 汉川市| 平顺县| 闵行区| 大足县| 正安县| 博客| 财经| 加查县| 都江堰市| 息烽县| 文昌市| 拜泉县| 西宁市| 陇西县| 奉新县| 吉木萨尔县| 金阳县| 绥中县| 和田县| 洮南市| 湖州市| 乡城县| 冕宁县| 揭西县| 澳门| 长沙市| 仙游县| 山阴县| 泰顺县| 驻马店市| 乃东县| 广州市| 祁东县| 马鞍山市| 桦川县| 广德县|