2008年11月18日 #

语录一

某天,停车,图方便随便停在路边,抱怨了两句,ld随即顶回一句:“只要有边就能停”

posted @ 2008-11-18 23:32 tacy lee 阅读(191) | 评论 (0)编辑 收藏

2008年6月24日 #

oracle 的lob & long

一直认为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

posted @ 2008-06-24 01:18 tacy lee 阅读(373) | 评论 (0)编辑 收藏

2008年6月22日 #

杀掉服务器上的远程桌面连接

用远程桌面连接登入服务器的时候,你可能会经常碰到下面的情况:

mstsc-exceed-456x114

 

也就是说,服务器的连接数已经满了,很多时候,可能是别人异常断开连接,导致连接没有释放,一般这时候你需要去机房登入服务器断开连接,其实windows提供了tsdiscon命令来做这事情

posted @ 2008-06-22 17:12 tacy lee 阅读(398) | 评论 (0)编辑 收藏

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文件就能看到错误页面了

非常有效的一个小技巧,用它解决了一个难缠的问题。

posted @ 2008-05-28 23:05 tacy lee 阅读(753) | 评论 (3)编辑 收藏

2008年5月18日 #

捐款

慢慢变味了,一群无聊的人整天盯着别人捐了多少,很奇怪

posted @ 2008-05-18 19:45 tacy lee 阅读(185) | 评论 (0)编辑 收藏

2008年5月14日 #

地震

最近一段时间特别忙,以至于发生地震这么大的事情都没注意到,首都人民不断告诉我被震了也没当回事,昨晚回家打开电视,新闻频道,懵了,坐下来一直看,到晚上2点,满目苍痍,真为处于震中的人揪心,中间鼻子酸了N次,也愤怒了N次(那些恶心人的地方官,难道就不能说点实际的东西吗?)

1、政府反映非常迅速
2、子弟兵真好
2、有一个好总理
3、地方政府不作为,官话套话(被采访的那个什么何彪,真想抽丫的)
4、为什么总是学校?处于地址多发地带的学校和其他公共设施为什么都是豆腐渣

为所有受难的人祈祷!为我们饱受磨难的祖国祈祷!

公司员工捐款20W,尽点绵力

posted @ 2008-05-14 10:17 tacy lee 阅读(173) | 评论 (0)编辑 收藏

2008年4月14日 #

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

     摘要: 这几天测试一个引擎的性能,用一个单表查询的case,测试出来的结果是210tps,cpu也正常,在85%左右,也没怀疑。

后面再重新测试的时候,加上了gc log,用gc分析工具分析了一下gc的吞吐量,发现吞吐量奇低,竟然只有77%左右,很是奇怪,看了一下gc日志,所有都是global gc, 怀疑gc策略有问题,查了一下资料,参考了下面一篇文章:  阅读全文

posted @ 2008-04-14 20:38 tacy lee 阅读(4227) | 评论 (2)编辑 收藏

2008年4月1日 #

Sybase 锁模式

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

posted @ 2008-04-01 10:50 tacy lee 阅读(754) | 评论 (0)编辑 收藏

2008年3月18日 #

并发是啥

一个用户点击就是一个用户请求,一个webservice类似的调用也算一个请求,等等


一个用户在某个时间点上当然只能发起一个用户请求,一个用户请求就是一个并发

我们一般纠缠在同一事物并发还是不同事务并发。

可能在一个时间点上,有100个用户在发送浏览,查询动作,10个用户在下订单,5个用户在做付款动作,你说这个时间点上有多少个并发请求,当然是115个了

衡量一个系统性能主要靠的就是这个吞吐量(tps)

当然我们也非常关心同时100个用户并发下订单的时候系统是否能支撑(这是通常我们大部分人理解的并发),我们会说这是核心业务,我们要得出数据(是否要考虑背景业务呢,呵呵,很难说的清楚,我一般就不考虑)

posted @ 2008-03-18 15:33 tacy lee 阅读(233) | 评论 (0)编辑 收藏

2008年3月16日 #

工作日志-OOM事件

某项目,年前开始报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问题

posted @ 2008-03-16 22:38 tacy lee 阅读(2582) | 评论 (2)编辑 收藏

仅列出标题  下一页