2007年12月21日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認為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小，當然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產(chǎn)生的redo比long大，就不列出來了，有興趣的可以自己試試
測試下來，看來之前的認識不對，不確定的東西最好還是動手試試，當然對于新應(yīng)用，還是不建議用long，畢竟oracle已經(jīng)廢棄它了。
testClobLong.java
用遠程桌面連接登入服務(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輸出保存到日志文件
當然你不要下載資源文件，否則保存到的就不是html頁面了，可能是一個gif :(
最后，結(jié)合lr controller的錯誤信息，定位到出錯的vuser id，查看該vuser的log文件就能看到錯誤頁面了
非常有效的一個小技巧，用它解決了一個難纏的問題。
慢慢變味了，一群無聊的人整天盯著別人捐了多少，很奇怪
最近一段時間特別忙，以至于發(fā)生地震這么大的事情都沒注意到，首都人民不斷告訴我被震了也沒當回事，昨晚回家打開電視，新聞頻道，懵了，坐下來一直看，到晚上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都加頁鎖（當頁被鎖住的時候，頁上的所有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)用也算一個請求，等等
一個用戶在某個時間點上當然只能發(fā)起一個用戶請求，一個用戶請求就是一個并發(fā)
我們一般糾纏在同一事物并發(fā)還是不同事務(wù)并發(fā)。
可能在一個時間點上，有100個用戶在發(fā)送瀏覽，查詢動作，10個用戶在下訂單，5個用戶在做付款動作，你說這個時間點上有多少個并發(fā)請求，當然是115個了
衡量一個系統(tǒng)性能主要靠的就是這個吞吐量（tps）
當然我們也非常關(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，獲取詳細的GC log），后面仔細檢查nohup.out,發(fā)現(xiàn)里面已經(jīng)拋出了 OutOfMemoryError:PermGen Space，至此我們確定是Perm設(shè)置不合理導(dǎo)致了本次事故，和客戶確認之后，我們在啟動參數(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問題
之前就準備了一堆的片子，好好享受了一把，留下幾部有映象的吧：
強烈推薦型：
咱們自家的片子先推薦：《盲山》
看盲山，讓我想起Michael Moore，我一直認為，嚴肅題材的電影本身就是電影存在的意義所在，我們需要用影像真實的記錄這個時代，我們需要這些“冷名人”，他們也許不是名利場的寵兒，但是他們一樣會有無數(shù)喜歡他們的人
《我在伊朗長大》
聽主人公瑪嘉娓娓道來，伊朗社會的變遷，依稀可以看到我們的影子，影片沒有去譴責或者反省或者什么高深的立意，只是要告訴你這個社會的樣子
《進退維谷》
只要是Paul Haggis，都值得你關(guān)注，呵呵，反戰(zhàn)的片子，我感覺比之前的撞車有過之而無不及，不知為啥挺冷的，Tommy應(yīng)該提名最佳男演員，不過他好像評老無所依提名
《偷心》
老片子，看吧，不后悔，愛死這個精靈古怪的Natalie了，哈哈，真真假假誰又能分得清楚呢
《老無所依》
那個僵尸男實在太酷了，Tommy今年也挺火的，哈哈
隨便看看：
神探，喜歡記憶碎碎片，搏擊俱樂部這類片子的人可以看看，劉青云的表演我個人覺得一般，反正也就
美國黑幫（Denzel Washington新片，值得一看）
諜影重重3（這個還是比較經(jīng)典，今年馬特達蒙很火，整部片子非常緊湊，緊張刺激），
我的盛大同志婚禮（無厘頭Adam Sandler，去年的神奇遙控器記憶猶新），
一年到頭（騙了我一把眼淚）
C+偵探
贖罪（最近很火，看看吧）
哈哈，不記得了，還有一些，另外看了第一季反恐24，感覺一般
http://www.tudou.com/programs/view/yKJB_VzHXYU/
突然覺得，這一年收獲很多，感觸很多，需要仔細總結(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)呢，哈哈
之前一直認為類似：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情況下，走索引
糾正我之前的認識。
另外再補充一下，date這個數(shù)據(jù)類型一般情況下很少用，建議產(chǎn)品里面所有的date數(shù)據(jù)類型全部改為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"，這樣應(yīng)用類可以覆蓋父裝載器的類
當然但如果你混合使用了被覆蓋的類和沒有被覆蓋的類，則此操作有可能會導(dǎo)致 ClassCastException 或 LinkageErrors
2、在"Servers" > "Application servers" > "yourserver" > "Process Definition" > "Java Virtual Machine"
添加CLASSPATH，讓你的類先加載