2007年10月23日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認為lob類型的性能要好過long，但是之前只了解到long的種種限制，oracle也是不推薦使用long類型，這幾天由于一個項目問題，產品里面一個表字段用了long類型，分析下來操作long的時候，性能有所影響，想把它改成lob，就簡單驗證了一下
首先創建兩個測試表：
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼，往兩個表里面各插入100條數據，保證插入數據是一樣的，lob字段長度為10k（如果小于4k，oracle可以把它保存到到表內，不會存儲在表外，性能沒有問題，這個我基本確定，而且我們應用中這個字段經常會超過4k）。
做一個簡單查詢對比一下：
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統計信息
----------------------------------------------------------
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;
統計信息
----------------------------------------------------------
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小，當然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產生的redo比long大，就不列出來了，有興趣的可以自己試試
測試下來，看來之前的認識不對，不確定的東西最好還是動手試試，當然對于新應用，還是不建議用long，畢竟oracle已經廢棄它了。
testClobLong.java
用遠程桌面連接登入服務器的時候，你可能會經常碰到下面的情況：
也就是說，服務器的連接數已經滿了，很多時候，可能是別人異常斷開連接，導致連接沒有釋放，一般這時候你需要去機房登入服務器斷開連接，其實windows提供了tsdiscon命令來做這事情
有時候，我們可能希望看到lr的出錯頁面：比如lr出錯，但是后臺服務器沒有錯誤日志，這時候，我們希望能看到錯誤頁面的內容來判斷問題出在什么地方，但是lr沒有提供類似的功能
我們可以通過一種變通的辦法來實現：
首先找到你出錯的頁面，保存該頁面到參數里面：
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的幾個設置：
1、Always send messages
2、continue on error （這樣才能保證運行lr_output_message)
這樣lr會把所有的lr_output_message輸出保存到日志文件
當然你不要下載資源文件，否則保存到的就不是html頁面了，可能是一個gif :(
最后，結合lr controller的錯誤信息，定位到出錯的vuser id，查看該vuser的log文件就能看到錯誤頁面了
非常有效的一個小技巧，用它解決了一個難纏的問題。
慢慢變味了，一群無聊的人整天盯著別人捐了多少，很奇怪
最近一段時間特別忙，以至于發生地震這么大的事情都沒注意到，首都人民不斷告訴我被震了也沒當回事，昨晚回家打開電視，新聞頻道，懵了，坐下來一直看，到晚上2點，滿目蒼痍，真為處于震中的人揪心，中間鼻子酸了N次，也憤怒了N次（那些惡心人的地方官，難道就不能說點實際的東西嗎？）
1、政府反映非常迅速
2、子弟兵真好
2、有一個好總理
3、地方政府不作為，官話套話（被采訪的那個什么何彪，真想抽丫的）
4、為什么總是學校？處于地址多發地帶的學校和其他公共設施為什么都是豆腐渣
為所有受難的人祈禱！為我們飽受磨難的祖國祈禱！
公司員工捐款20W，盡點綿力
摘要: 這幾天測試一個引擎的性能，用一個單表查詢的case，測試出來的結果是210tps，cpu也正常，在85%左右，也沒懷疑。
后面再重新測試的時候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發現吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問題，查了一下資料，參考了下面一篇文章：
閱讀全文
Sybase ASE有三種鎖模式：AllPages,DataPages,DataRows
Sybase的數據有table pages和index pages，最小分配單位為pages，不同的鎖模式對于table pages和index pages有不同的表現，具體如下：
| Locking Schema | Locks on Index | Locks on Data |
| All Pages | Page | Page |
| DataPages | Not locked | Page |
| DataRows | Not locked | Row |
如上表所示：
1、AllPages鎖模式對于并發的限制最高，他對index pages和table pages都加頁鎖（當頁被鎖住的時候，頁上的所有rows都不能被其他session訪問）
2、DataPages對table pages加頁鎖
3、DataRows：強烈建議用這個鎖模式，對于oltp應用，如果用前兩種鎖模式會導致頻繁死鎖
另外，DataPages和DataRows對于index pages的控制采用latch方式，一種輕量級的鎖機制（熟悉oracle會比較清楚）
對于Sybase ASE來說，鎖是非常寶貴的資源，不要長時間持有鎖，所以一般我們在寫應用的時候盡量減少長事務
另：Sybase ASE缺省的事務隔離級別：Read Committed
一個用戶點擊就是一個用戶請求，一個webservice類似的調用也算一個請求，等等
一個用戶在某個時間點上當然只能發起一個用戶請求，一個用戶請求就是一個并發
我們一般糾纏在同一事物并發還是不同事務并發。
可能在一個時間點上，有100個用戶在發送瀏覽，查詢動作，10個用戶在下訂單，5個用戶在做付款動作，你說這個時間點上有多少個并發請求，當然是115個了
衡量一個系統性能主要靠的就是這個吞吐量（tps）
當然我們也非常關心同時100個用戶并發下訂單的時候系統是否能支撐（這是通常我們大部分人理解的并發），我們會說這是核心業務，我們要得出數據（是否要考慮背景業務呢，呵呵，很難說的清楚，我一般就不考慮）
某項目，年前開始報OOM，頻率保持在一月一次，發生OOM的時候，heap free size還有7～800M，比較奇怪，年后系統上集群，系統發生OOM的頻率開始變得頻繁，基本在4-5天，由于用的是sun jdk 1.4.2_08，無法獲取到heap dump，建議用戶升級到1.4.2_14（該版本以后sun添加了HeapDumpOnOutOfMemoryError參數，便于獲取dump幫助診斷該類問題），4天之后，我們獲取到了heapdump文件，通過對dump的分析，基本上排除了對象泄漏。
根據環境（64bit Solaris + 32bit JDK），客戶把Heap最大設置為2G，開始懷疑32bit JDK無法分配這么大的Heap，經過驗證，不存在這樣的問題（sun網站也有相關說明，在solaris 64bit系統上，32bit jdk最大可以設置到4G）
但是從dump看到application classes loader大小已經到了60M以上，有點懷疑Perm區設置太小導致，查了一下sun的文檔，Perm區缺省大小為64M，估計是應用加載太多classes導致Perm區溢出，
我們也簡單模擬了一下Perm溢出，強制設置max perm大小為32M，并對GC進行了監控，結果和我們預想的一致，看下面的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
從日志看，和我們現場的狀況非常相似，heap空間充足，但是perm已經到了32M，無法再進一步分配空間，直接導致jvm頻繁做Full GC，控制臺也開始拋出OOM（Perm引起的回收都是full gc），這樣看基本我們判斷是Perm太小，導致無法加載classes導致的
和客戶溝通之后，我們本來打算進一步驗證（在生產環節打開PrintGCDetail，獲取詳細的GC log），后面仔細檢查nohup.out,發現里面已經拋出了 OutOfMemoryError:PermGen Space，至此我們確定是Perm設置不合理導致了本次事故，和客戶確認之后，我們在啟動參數中加上了MaxPermSize
后面想到中間上了集群之后，eos加載了大量的jboss cache class，這也直接解釋了為什么這段時間OOM出現的頻率比之前更頻繁的原因
這里總結一下，希望對碰到類似問題的tx有借鑒意義，強烈建議用sun jdk 1.4.2的同學升級到>=1.4.2_12，便于對OOM問題的診斷，并加上GC log協助驗證。
這里再介紹一下JVM發生OOM的幾種情況：
1、java.lang.OutOfMemoryError: Java heap space
這是我們平常理解的OOM，是由于heap space確實沒有空間分配，這種一般是由于內存泄漏導致，也有可能是heap space設置太小。需要具體分析
2、java.lang.OutOfMemoryError: PermGen space
jvm規范里面有定義一個method space，這里主要放classes和method list和一個string pool，string有一個intern方法，通過這個方法定義的string都放在這里（好像不常用），這里設置不太小會導致OOM，缺省64M，主要由于現在應用依賴的第三方類越來越多，導致這類問題頻繁發生，需要引起重視
3、Requested array size exceeds VM limit
這種是由于申請的array size超出了heap space大小，比如在一個256M的heap space中申請一個512M的array，這種基本都是應用bug導致
4、request <size> bytes for <reason>. Out of swap space?
這種是由于heap size設置相對于系統物理內存太大，導致系統swap space不足，這種的解決辦法就是減小heap size大小
5、<reason> <stack trace> (Native method)
這種估計是最麻煩的了，也是最少碰到的，是由于jni或native method導致，如果自己沒有寫這類的東西，基本可以說是jdk問題
之前就準備了一堆的片子，好好享受了一把，留下幾部有映象的吧：
強烈推薦型：
咱們自家的片子先推薦：《盲山》
看盲山，讓我想起Michael Moore，我一直認為，嚴肅題材的電影本身就是電影存在的意義所在，我們需要用影像真實的記錄這個時代，我們需要這些“冷名人”，他們也許不是名利場的寵兒，但是他們一樣會有無數喜歡他們的人
《我在伊朗長大》
聽主人公瑪嘉娓娓道來，伊朗社會的變遷，依稀可以看到我們的影子，影片沒有去譴責或者反省或者什么高深的立意，只是要告訴你這個社會的樣子
《進退維谷》
只要是Paul Haggis，都值得你關注，呵呵，反戰的片子，我感覺比之前的撞車有過之而無不及，不知為啥挺冷的，Tommy應該提名最佳男演員，不過他好像評老無所依提名
《偷心》
老片子，看吧，不后悔，愛死這個精靈古怪的Natalie了，哈哈，真真假假誰又能分得清楚呢
《老無所依》
那個僵尸男實在太酷了，Tommy今年也挺火的，哈哈
隨便看看：
神探，喜歡記憶碎碎片，搏擊俱樂部這類片子的人可以看看，劉青云的表演我個人覺得一般，反正也就
美國黑幫（Denzel Washington新片，值得一看）
諜影重重3（這個還是比較經典，今年馬特達蒙很火，整部片子非常緊湊，緊張刺激），
我的盛大同志婚禮（無厘頭Adam Sandler，去年的神奇遙控器記憶猶新），
一年到頭（騙了我一把眼淚）
C+偵探
贖罪（最近很火，看看吧）
哈哈，不記得了，還有一些，另外看了第一季反恐24，感覺一般
http://www.tudou.com/programs/view/yKJB_VzHXYU/
突然覺得，這一年收獲很多，感觸很多，需要仔細總結總結
應該來說，場面還是不錯的，國內戰爭大片
太追求效果了，說實話，看過之后就忘了，在腦海里沒留下啥東西，雖然沒經歷過戰爭，但是在解放戰爭年代的巷戰竟然打著手勢，為演戲而演戲，挺搞笑的，懷念黑鷹墜落中的那段伏擊戰，谷子地站在空地里手舞足蹈那段看著太怪了，這是戰爭嗎，整個讓人感覺挺滑稽的，像一群新兵蛋子第一次上戰場，哭爹喊娘，太過啦馮導
耳朵被轟的夠嗆，后面開始打感情牌，賺點眼淚
馮導還是要加油啊，其實大家是喜歡看馮導還是葛優呢，哈哈
之前一直認為類似：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;
表已創建。
sys@EOS> create index idx_test_date on test (date_test);
索引已創建。
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');
執行計劃
----------------------------------------------------------
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
統計信息
----------------------------------------------------------
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情況下，走索引
糾正我之前的認識。
另外再補充一下，date這個數據類型一般情況下很少用，建議產品里面所有的date數據類型全部改為timestamp
作者：tacy lee
由于大量開源框架的采用，Classes沖突的問題在我們的項目中越來越常見，下面寫了一個簡單的jsp，用來查找當前使用類的位置：
<%@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"，這樣應用類可以覆蓋父裝載器的類
當然但如果你混合使用了被覆蓋的類和沒有被覆蓋的類，則此操作有可能會導致 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另外提供很多其他語言的機器人，有興趣的可以去了解一下
官網已經發布消息，好像原定應該是21號發布嘛！
具體看
這里
-----------------------------------------------------------------------------------
update：
已經成功把自己的firefox升級到3，升級過程中，用的幾個插件手動調了一下版本限制，其中google toolbar和yahoo的delicious不行，刪除之，變通方案：
1、google toolbar我平時主要用來屏幕取詞，用backword替代
2、yahoo的delicious用老版本替代（delicious沒被收購時發布的那個）
用下來感覺速度確實快了很多，內存占用也少了，原來動不動就給我奔200M，現在穩定在90M左右，經常訪問的一些網站都顯示正常。
當然這里不是鼓勵大家升級，如果你平時用到一些大塊頭的插件，那最好等他們升級
列一下我用到的幾個插件：
Adblock Plus：廣告屏蔽，這個不用多說了
backword：屏幕取詞，主要是咱們英文太爛，看英文網站需要
del.icio.us：美味書簽，換成了delicious沒被yahoo收購時開發的，少了側邊欄查找，唯一遺憾
DictionarySearch：通過thefreedictionary查單詞(英英)，強烈推薦
FlashGot：下載管理器
Tab Control：沒用那個龐大無比的Tab Mix Plus，這個很小，只是實現新打開的tab在當前tab左邊，不要給我跑到最后去
Torbutton：洋蔥頭，翻墻用的
Vimperator：這個一般人估計不會用，只推薦給vi老手
作者：tacy lee
有用Websphere做過項目的人可能都知道，ibm一般都建議在Websphere前面加一個IHS來做webserver，據說這樣性能會提高30%左右，這樣說是否有道理呢，下面我做了一個簡單的測試來驗證：
測試環境：
硬件：
應用服務器：Dell6600
壓力測試客戶端：自用筆記本（T2050 1.6G)
軟件：
系統：CentOS 4.4
Websphere 6.0.2.17+IHS6.0.2.17（部署在同一臺機器上）
首先配置好Websphere和IHS，發布一個簡單的測試應用，用loadrunner來測試一下不同的組合看看（錄制一個打開首頁就可以了），下面是我的測試數據：
| 測試方法 | 每秒處理請求數 | 響應時間 | 服務器CPU |
| 直接請求Websphere | 4600/s | 0.013s | 28% |
| 通過IHS轉發請求 | 6800/s | 0.009s | 26% |
數據顯示，這還不是一點點提升，竟然快接近50%，把靜態資源放置到IHS中測試了一把，基本和通過IHS轉發差不多，稍微有些提升，不過放到IHS中可以方便Cache（Edge Server就包括了Caching Proxy component）
下面記錄一下如何放置靜態資源文件到IHS中：
1、打開Plugins中的plugin-cfg.xml，修改如下內容：
<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增加了一個自定義參數
com.ibm.ws.webcontainer.disallowAllFileServing
設定它為true產生同樣的效果（而且他會覆蓋ibm-web-ext.xmi中的設置）。
2、拷貝你的所有資源文件到IHS的Root Directory中
3、重啟IHS
作者：tacy lee
經常，我們在啟動應用的時候發現系統需要的端口被別的程序占用，如何知道誰占有了我們需要的端口，很多人都比較頭疼，下面就介紹一種非常簡單的方法，希望對大家有用
假如我們需要確定誰占用了我們的9050端口
1、Windows平臺
在windows命令行窗口下執行：
C:\>netstat -aon|findstr "9050"
TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 2016
看到了嗎，端口被進程號為2016的進程占用，繼續執行下面命令：
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竟然需要很長時間，網上查了查，有很多人碰到類似問題，但是一般都是關掉sendmail服務或者關掉dns了事，咱們現在要用它，自然不能關掉了事，dns也不能關，關了服務器沒法解析域名
毫無疑問，sendmail去做dns lookup，并且無法lookup到域名，在等待解析超時！
resolv里面也指定了nameserver，應該能正常做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
好像也沒發現啥不對的，他在解析啥呢，看看log去，找到/var/log/maillog（也可能在messages），看到如下內容：
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里面規定域名必須用"."結尾，難道是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，刷一下就啟動了，呵呵
回頭想想，問題其實很簡單，但是在網上卻沒找到什么好的方案，說明都挺懶得，能繞都繞過去了.
作者：tacy lee
在應用使用過程中，我們經常會碰到應用響應時間很慢，甚至沒有響應，但是應用服務器可能并不是很繁忙，cpu利用率也非常低，引起這種狀況的原因有很多種，比如環境問題，應用資源泄漏，數據庫原因等等，本文主要是從一次應用性能診斷過程來談談如何通過數據庫診斷應用性能問題。
問題：
測試過程中發現應用中某個跳轉頁面執行時間比較長，系統壓力不大，cpu利用很低，該頁面需要從cache中取數據，第一次的時候加載cache（從數據庫中查詢回數據并cache）。
診斷：
頁面邏輯比較簡單，我們先用loadrunner模擬并發測試一下這個頁面，然后再數據庫端捕獲sql執行情況。
1、打開db2監控開關
#db2 connect to eos
#db2 update monitor switches using statement on
#db2 reset monitor all
2、幾分鐘之后，我們收集sql統計快照
#db2 get snapshot for dynamic sql on eos > dysqlstatus.out
現在統計信息已經存放在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執行時間，我們要按照執行時間來排序
通過vim的visual功能選擇執行時間塊（等號后面的數字），然后排序
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
排序后的結果（部分）
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執行時間耗費了3797.905123s.
現在我們到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
這條語句總共執行了4602次，平均每次的執行時間2S，而且這些數據應該是被cache起來的 ；）
總結：
上面的方法簡單總結了從數據庫層面對應用的性能問題診斷，希望對大家有所幫助，對于數據庫快照診斷問題的思路對于任意數據庫通用
補充一個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
在應用中，我們經常會碰到sql執行很慢，但是數據庫cpu和內存使用率又不高的情況，類似的問題基本上由于鎖，排序等原因造成，本文主要描述如何去定位鎖等待問題，誰在鎖等待？等待誰持有的鎖？鎖在那個表？
一、測試準備
1、先在session1執行如下操作，創建測試表
#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執行如下操作
#db2 connect to eos
#export DB2OPTIONS=+C
二、產生一個lock wait
在session1做一個表更新：
#db2 "update tacy_test set b='b' where a=4"
sql執行成功
在session2做同樣更新操作：
#db2 "update tacy_test set b='c' where a=4"
進程被掛起等待
三、定位鎖等待
1、先來看看應用的情況：
#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
可以看到有一個應用的狀態處于Lock-wait
2、現在我們來看看應用在等什么
#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鎖（排他鎖），下面是我們最關心的鎖的位置
TbspaceID 2 TableID 1560 RecordID 0x2668007
其中TbspaceID為表空間ID，TableID為表的ID，RecordID代表具體位置，全部應該是0x0266807,其中前面三個字節為page number，為0x02668，后面一個字節代表solt identifier，為0x07
3、找到相應的表
#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、根據RecordID找到鎖在哪行
db2提供了一個強大的數據分析工具db2dart，可以dump出相應的page數據
#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)，需要轉換為十進制，在結尾必須加p，np代表你要獲取的頁數，v為是否詳細輸出
現在我們來看看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，你現在可以清楚的知道應用等待的Row為(4,a)
總結
通過上面的方法，我們簡單描述了一個db2鎖問題的定位方法，希望能給大家在分析和定位應用性能問題的時候起到一定的幫助
作者：tacy lee
一：基本介紹
在Loadrunner的使用中，對于Run-time Settings下的browser emulation設置是比較容易讓人產生困惑的地方。下面我們結合sniffer來具體看看每個選項的用途，以及對測試的影響。
Browser Emulation 圖
二：案例和工具
1. 測試案例：
打開網站首頁兩次，對比不同Browser Emulation設置下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
首先設置Run Logic中的iteration為2。讓Action運行兩次，看看循環運行腳本兩次，數據包和連接數的變化。
1. 去掉所有選項
結果：共獲取數據包95個，建立連接1個（紅色標識），斷開連接1個（藍色標識）
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
在這種情況下，數據包非常少（沒有選擇下載資源文件入css,js,gif等），而且你可以看到，打開4次首頁，只建立了一個tcp連接。
這時，你即使選擇A，發現數據包的數量量頁沒有變化，因為cache主要還是針對資源文件
2. 選擇E(F)
結果：共獲取數據包102個，建立連接2個（紅色標識），斷開連接2個（藍色標識）
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
在這種情況下，數據包非常少（沒有選擇下載資源文件入css,js,gif等），對比第一種情況，你會發現它建立了兩個連接，這就是E的作用，它對于每次迭代都當成一個新的用戶，需要重新建立連接。
3. 選擇DE(F)
結果：共獲取數據包1782個，建立連接6個（紅色標識），斷開連接6個（藍色標識）
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
在這種情況下，數據包的數量非常大，連接也很多，由于沒有cache功能，每次打開頁面都需要重新下載所有的資源文件。
4. 選擇ADE
結果：共獲取數據包525個，建立連接3個，斷開連接3個(不再標識了，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發揮作用，數據包對比第三種情況大大減少，幾乎等于打開一次首頁的數據量（449個數據包），只有第一次打開頁面需要完整下載頁面（包括資源文件），后面的三次打開頁面都只要下載HTML頁面（不包括資源文件）。
5. 選擇ADEF
選擇F之后我們看看結果：共獲取數據包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，所以每次迭代都需要重新下載資源文件。數據包差不多等于第三種情況的一半，約等于打開兩次首頁的數據量（449×2個數據包）。
6. 關于BC選項
C的解釋（Check for newer versions of stored pages every visit to the page）
C比較容易理解，類似IE設置中的每次檢查，如果不設置C，LR對于已經cache的文件就不會重新向服務器請求，如果選擇C，你就可以在數據包中發現很多304信息。
B的解釋（Cache URLs requiring content(HTMLs)）
LR對于資源文件的cache并不會真正cache在內存中或者在磁盤上，這個選項表示：對于一些需要用到的關聯，校驗，頁面解析內容真正cache在內存中，減少客戶端的重復工作。
當然如果你想把GIF也cache到內存中，你可以在Advanced中設置，選擇Specify URL requiring content in addition to HTML pages，加入條目image/gif，并勾選。當Vuser運行的時候，你可以對比一下mmdrv.exe進程的內存消耗（內存占用會更多）。
四： 結論
通過上面的測試分析，我們大概知道了每個選項的真正含義，你需要根據你的測試目的來選擇合適的設置：
1、 對于一個具體的應用測試，對于前端Web Server不可忽略，缺省設置非常合適，不需要調整（有時候需要考慮把C選上）
注意：很多人在錄制腳本的時候，習慣把登入操作放到vuser_init中，這時候缺省設置可能會拋錯，建議把這類的操作都放入到action中
2、 如果你更關注后端應用服務器的性能或者說做一些架構的驗證分析，那你缺省設置對于你來說就不合適了，你需要選擇取消所有的設置項。
當然你也可以根據自己的具體情況做不同調整，但是一定要真正理解這些選項的具體含義才能做到不犯錯誤
編譯的時候出現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的中文字符集），導致stack區溢出（明顯沒對國際化測試不足嘛）
解決問題的方法就是修改系統的缺省區域設置為English既可。
del.icio.us Tags:
java ,
ant ,
build ,
tips
故障現象：
測試一段時間后應用無響應，連接池不能放大，jvm crash，日志報對象分配失敗
問題診斷：
第一個階段是websphere問題
到現場之后，回放腳本測試幾分鐘，應用開始無法響應，后臺也沒有異常，update jdk之后，系統能正常響應了，但是發現新的問題，db2連接池始終無法放大，最大只能到30，而且系統也會拋OOM，導致系統異常推出，從系統日志看，是因為應用中的大對象分配導致的（2M大小）
期間，關于連接池無法放大問題想了很多辦法，包括修改db2 maxappls,maxagents這些參數，更新數據庫驅動，而且確定不是db2的問題（在創建30之后，我們依然可以通過其他方式連接到db2，說明db2的連接限制確實放大了），當然我們productdatasource這個池子大小我已經放大到100了。
中間還發現測試腳本沒有正常啟動流程，排查后發現是loadrunner的問題，用我機器上的lr錄制正常（錯誤代碼提示是字段長度限制，莫名其妙）。
關于jvm crach我們也調整了heap設置：-xms256m,-xmx1536m
但是問題依然存在。后面我們重新安裝了應用，所有的設置采用缺省配置，沒有打任何補丁，系統這個時候竟然可以正常跑了，只是響應很慢，而且時間曲線一直往上拋（測試一段時間系統無響應）
查了一下配置，發現productdatasource的缺省設置竟然就是30，這個時候基本判斷是之前的websphere的設置修改沒有生效
重新修改jvm和連接池配置，這時候系統正常，數據連接也達到83個，然后開始測試大并發量
階段二就是調整數據庫配置
1、第一個是db2 default buffer pool，缺省配置buffer才4m，這個一定要注意修改
2、第二個是db2的lock數量，在缺省基礎上好像放大了100倍
3、sort heap，排序區（防止排序溢出）
這些調整都要通過db2的狀態來調整，可以通過get snapshot指令來獲得數據庫狀態，buffer不夠會出現大量的邏輯讀，lock不夠會拋lock溢出(會導致鎖升級），sort heap不夠會提示排序溢出（這時候排序會在硬盤做）
回頭看看這次支持：
1、websphere配置修改不生效，我后面仔細想了想，這個websphere很多公司用可能大家都亂改了一通，另一問題是我們的使用習慣，websphere強烈不建議用kill直接殺進程方式停服務器，websphere不但是一個java進程，還有很多的附屬進程，直接kill也很容易導致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日志，如果出現OOM，這里會有記錄，當發現OOM的時候，可以打開jvm的verbosegc，分析verbosegc和jvm dump file，上面文檔里提到一個很重要的東西就是pinned對象，這也是ibm為啥不建議設置ms=mx的原因。
先建立一個監控器
db2 "create event monitor SQLCOST for statements write to file '/home/db2inst1'"
再設置事務狀態為打開
db2 "set event monitor SQLCOST state=1"
注：1為打開，0為關閉，收集數據之后，記得關閉你的監控器，否則。。。
跑你的測試后，在你的/home/db2inst1目錄下會生成一些evm文件
用下面指令獲取診斷信息：
db2evmon -db eos51 -evm SQLCOST>sqlcost1.txt
完成之后刪除你的監控器
db2 "drop event monitor SQLCOST"
生成的采樣例子，從下面的例子中，你可以清除的看到SQL執行的時間，CPU消耗情況，排序是否溢出，BufferPool的使用情況，根據這些信息，SQL的執行效率一目了然：
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執行時間和CPU消耗情況
[licl2]SQL的排序情況，可以看到這個SQL沒有排序，當然也沒有排序溢出
[licl3]Bufferpool的使用情況，邏輯讀和物理讀的對比
del.icio.us Tags:
database ,
db2 ,
tuning
作者：tacy lee
簡單介紹一下Loadrunner Analysis中的Web Page Diagnostics模塊的使用，很多人對于測試之后的結果數據分析摸不著頭腦，其實loadrunner Analysis給你提供了很好的文檔，大家沒事可以多翻翻，多翻幾遍對于性能測試你就入門了 ；）
Web Page Diagnostics （以下簡稱WPD），這是LR Analysis中非常重要的一塊，搞清楚這部分的內容會讓你少走很多彎路，很多環境問題都可以通過它來定位，比如客戶端，網絡。通過它可以你可以比較好的來定位是環境的問題還是應用本身的問題，當然更重要的是Web頁面本身的問題。
WPD包括下面幾個圖表：
Web Page Diagnostics 這是張總圖，包括下面幾張Over Time圖的內容
Page Component Breakdown 頁面中每個元素的平均響應時間占整個頁面響應時間的百分比
Page Component Breakdown(Over Time) 在整個測試過程中，任意一秒內頁面中每個元素的響應時間（例如在runtime中設置了browser cache，頁面中的資源文件就只會在第一次下載，后面的頁面響應時間也就不包括這些元素的時間，這在Page Component Breakdown中是看不出來的，因為Page Component Breakdown是整個測試期間內的平均時間。當然，是否啟用了cache，通過over time圖就能看出來）
Page Download Time Breakdown 頁面中每個元素的響應時間分割圖，響應時間被分割為以下幾個部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error
Page Download Time Breakdown(Over Time) 在整個測試過程中，任意一秒內頁面中每個元素的響應時間分割圖
Time to First Buffer Breakdown First Buffer Time時間分割為Network Time和Server Time，客戶端http請求發送到接收到服務器端的應答包（ACK）為Network Time，從接收到ACK到完成First Buffer接受為Server Time
Time to First Buffer Breakdown(Over Time) 基本同上，任意一秒內的
Downloaded Component Size(KB) 頁面中每個元素的大小（KB）
介紹了這么多，具體如何分析呢？
首先打開Web Page Diagnostics圖，來看看下面一個例子Download Time圖：
上圖存在兩個問題：
1、receive時間很長
這個一般是網絡問題，當然如果你確認網絡不存在問題，那么你就要看看是不是客戶端的問題（客戶端也可能會造成Receive過長，這個千萬要注意）
2、頁面問題
頁面上包括了非常多的圖片，而且圖片似乎都沒有優化，最大的竟然有163K，記下來，這可是罪證哦 ；）
很多時候，你可以根據DNS,Connection,Receive來看出是否存在網絡問題，根據Client來判斷是否存在客戶端問題。
看看，挺簡單的吧！ ^_^
換個圖看看，Page Component Breakdown(Over Time)
很清楚吧，頁面元素都被cache了，說明場景啟用了browser cache，頁面的響應時間只包括紅線和藍線。
Time to First Buffer Breakdown(Over Time) ，圖就不貼了，這個圖非常重要，也最復雜，這里的值不絕對，當網絡狀況不好的時候，server time很可能包括網絡時間，因為很多頁面元素比較小（小于4k的樣子），在First Buffer就完成傳輸，所以一定要注意分析。
就嘮叨到這里吧，歡迎拍磚