2007年10月23日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認(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
用遠(yuǎn)程桌面連接登入服務(wù)器的時候，你可能會經(jīng)常碰到下面的情況：
也就是說，服務(wù)器的連接數(shù)已經(jīng)滿了，很多時候，可能是別人異常斷開連接，導(dǎo)致連接沒有釋放，一般這時候你需要去機房登入服務(wù)器斷開連接，其實windows提供了tsdiscon命令來做這事情
有時候，我們可能希望看到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文件就能看到錯誤頁面了
非常有效的一個小技巧，用它解決了一個難纏的問題。
慢慢變味了，一群無聊的人整天盯著別人捐了多少，很奇怪
最近一段時間特別忙，以至于發(fā)生地震這么大的事情都沒注意到，首都人民不斷告訴我被震了也沒當(dāng)回事，昨晚回家打開電視，新聞頻道，懵了，坐下來一直看，到晚上2點，滿目蒼痍，真為處于震中的人揪心，中間鼻子酸了N次，也憤怒了N次（那些惡心人的地方官，難道就不能說點實際的東西嗎？）
1、政府反映非常迅速
2、子弟兵真好
2、有一個好總理
3、地方政府不作為，官話套話（被采訪的那個什么何彪，真想抽丫的）
4、為什么總是學(xué)校？處于地址多發(fā)地帶的學(xué)校和其他公共設(shè)施為什么都是豆腐渣
為所有受難的人祈禱！為我們飽受磨難的祖國祈禱！
公司員工捐款20W，盡點綿力
摘要: 這幾天測試一個引擎的性能，用一個單表查詢的case，測試出來的結(jié)果是210tps，cpu也正常，在85%左右，也沒懷疑。
后面再重新測試的時候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發(fā)現(xiàn)吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問題，查了一下資料，參考了下面一篇文章：
閱讀全文
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
一個用戶點擊就是一個用戶請求，一個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ù)呢，呵呵，很難說的清楚，我一般就不考慮）
某項目，年前開始報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問題
之前就準(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，感覺一般
http://www.tudou.com/programs/view/yKJB_VzHXYU/
突然覺得，這一年收獲很多，感觸很多，需要仔細(xì)總結(jié)總結(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)呢，哈哈
之前一直認(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
作者：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，讓你的類先加載
如果你使用gtalk，你可以使用google最近提供的翻譯機器人幫你翻譯
只需要添加如下兩個機器人帳號到你的gtalk好友列表中：
en2zh@bot.talk.google.com
zh2en@bot.talk.google.com
嘿嘿，你就可以讓他們幫你翻譯啦！
google另外提供很多其他語言的機器人，有興趣的可以去了解一下
官網(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老手
作者：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
作者：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:
aix,
windows,
tips
作者：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)上卻沒找到什么好的方案，說明都挺懶得，能繞都繞過去了.
作者：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）
作者：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)用性能問題的時候起到一定的幫助
作者：tacy lee
一：基本介紹
在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運行兩次，看看循環(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)整，但是一定要真正理解這些選項的具體含義才能做到不犯錯誤
編譯的時候出現(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:
java ,
ant ,
build ,
tips
故障現(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的原因。
先建立一個監(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:
database ,
db2 ,
tuning
作者：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圖：
上圖存在兩個問題：
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)
很清楚吧，頁面元素都被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就完成傳輸，所以一定要注意分析。
就嘮叨到這里吧，歡迎拍磚