2008年11月18日
#
某天，停车，图方便随便停在路边，抱怨了两句，ld随即顶回一句：“只要有边就能停”
2008年6月24日
#
一直认为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
2008年6月22日
#
用远程桌面连接登入服务器的时候，你可能会经常碰到下面的情况：
也就是说，服务器的连接数已经满了，很多时候，可能是别人异常断开连接，导致连接没有释放，一般这时候你需要去机房登入服务器断开连接，其实windows提供了tsdiscon命令来做这事情
2008年5月28日
#
有时候，我们可能希望看到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文件就能看到错误页面了
非常有效的一个小技巧，用它解决了一个难缠的问题。
2008年5月18日
#
慢慢变味了，一群无聊的人整天盯着别人捐了多少，很奇怪
2008年5月14日
#
最近一段时间特别忙，以至于发生地震这么大的事情都没注意到，首都人民不断告诉我被震了也没当回事，昨晚回家打开电视，新闻频道，懵了，坐下来一直看，到晚上2点，满目苍痍，真为处于震中的人揪心，中间鼻子酸了N次，也愤怒了N次（那些恶心人的地方官，难道就不能说点实际的东西吗？）
1、政府反映非常迅速
2、子弟兵真好
2、有一个好总理
3、地方政府不作为，官话套话（被采访的那个什么何彪，真想抽丫的）
4、为什么总是学校？处于地址多发地带的学校和其他公共设施为什么都是豆腐渣
为所有受难的人祈祷！为我们饱受磨难的祖国祈祷！
公司员工捐款20W，尽点绵力
2008年4月14日
#
摘要: 这几天测试一个引擎的性能，用一个单表查询的case，测试出来的结果是210tps，cpu也正常，在85%左右，也没怀疑。
后面再重新测试的时候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，发现吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 怀疑gc策略有问题，查了一下资料，参考了下面一篇文章：
阅读全文
2008年4月1日
#
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
2008年3月18日
#
一个用户点击就是一个用户请求，一个webservice类似的调用也算一个请求，等等
一个用户在某个时间点上当然只能发起一个用户请求，一个用户请求就是一个并发
我们一般纠缠在同一事物并发还是不同事务并发。
可能在一个时间点上，有100个用户在发送浏览，查询动作，10个用户在下订单，5个用户在做付款动作，你说这个时间点上有多少个并发请求，当然是115个了
衡量一个系统性能主要靠的就是这个吞吐量（tps）
当然我们也非常关心同时100个用户并发下订单的时候系统是否能支撑（这是通常我们大部分人理解的并发），我们会说这是核心业务，我们要得出数据（是否要考虑背景业务呢，呵呵，很难说的清楚，我一般就不考虑）
2008年3月16日
#
某项目，年前开始报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问题