语录一

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

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 阅读(432) | 评论 (0) | 编辑 收藏

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

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

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

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

通过保存错误页面到日志中解决一些后台看不到异常的错误

有时候，我们可能希望看到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 阅读(802) | 评论 (3) | 编辑 收藏

捐款

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

地震

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

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

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

Sybase 锁模式

Sybase ASE有三种锁模式：AllPages,DataPages,DataRows

Sybase的数据有table pages和index pages，最小分配单位为pages，不同的锁模式对于table pages和index pages有不同的表现，具体如下：

如上表所示：
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 阅读(906) | 评论 (0) | 编辑 收藏

并发是啥

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

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

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

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

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

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

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

工作日志-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 阅读(2709) | 评论 (2) | 编辑 收藏

观影日记

之前就准备了一堆的片子，好好享受了一把，留下几部有映象的吧：

强烈推荐型：

咱们自家的片子先推荐：《盲山》

看盲山，让我想起Michael Moore，我一直认为，严肃题材的电影本身就是电影存在的意义所在，我们需要用影像真实的记录这个时代，我们需要这些“冷名人”，他们也许不是名利场的宠儿，但是他们一样会有无数喜欢他们的人

《我在伊朗长大》

听主人公玛嘉娓娓道来，伊朗社会的变迁，依稀可以看到我们的影子，影片没有去谴责或者反省或者什么高深的立意，只是要告诉你这个社会的样子

《进退维谷》

只要是Paul Haggis，都值得你关注，呵呵，反战的片子，我感觉比之前的撞车有过之而无不及，不知为啥挺冷的，Tommy应该提名最佳男演员，不过他好像评老无所依提名

《偷心》

老片子，看吧，不后悔，爱死这个精灵古怪的Natalie了，哈哈，真真假假谁又能分得清楚呢

《老无所依》

那个僵尸男实在太酷了，Tommy今年也挺火的，哈哈

随便看看：

神探，喜欢记忆碎碎片，搏击俱乐部这类片子的人可以看看，刘青云的表演我个人觉得一般，反正也就

美国黑帮（Denzel Washington新片，值得一看）

谍影重重3（这个还是比较经典，今年马特达蒙很火，整部片子非常紧凑，紧张刺激），

我的盛大同志婚礼（无厘头Adam Sandler，去年的神奇遥控器记忆犹新），

一年到头（骗了我一把眼泪）

C+侦探

赎罪（最近很火，看看吧）

哈哈，不记得了，还有一些，另外看了第一季反恐24，感觉一般

posted @ 2008-02-13 14:02 tacy lee 阅读(229) | 评论 (0) | 编辑 收藏

公司同事拍的mv 欢迎捧场！

posted @ 2008-02-01 13:26 tacy lee 阅读(228) | 评论 (0) | 编辑 收藏

集结号

应该来说，场面还是不错的，国内战争大片

太追求效果了，说实话，看过之后就忘了，在脑海里没留下啥东西，虽然没经历过战争，但是在解放战争年代的巷战竟然打着手势，为演戏而演戏，挺搞笑的，怀念黑鹰坠落中的那段伏击战，谷子地站在空地里手舞足蹈那段看着太怪了，这是战争吗，整个让人感觉挺滑稽的，像一群新兵蛋子第一次上战场，哭爹喊娘，太过啦冯导

耳朵被轰的够呛，后面开始打感情牌，赚点眼泪

冯导还是要加油啊，其实大家是喜欢看冯导还是葛优呢，哈哈

posted @ 2008-01-04 16:05 tacy lee 阅读(246) | 评论 (4) | 编辑 收藏

关于oracle中的timestamp和date类型

posted @ 2007-12-26 00:42 tacy lee 阅读(1892) | 评论 (0) | 编辑 收藏

Websphere Classes冲突诊断

作者：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，让你的类先加载

posted @ 2007-12-21 18:05 tacy lee 阅读(1321) | 评论 (0) | 编辑 收藏

google提供的翻译机器人

posted @ 2007-12-20 17:04 tacy lee 阅读(237) | 评论 (0) | 编辑 收藏

firefox 3 beta 2释放出来了

posted @ 2007-12-19 14:58 tacy lee 阅读(283) | 评论 (0) | 编辑 收藏

Websphere到底是否需要配置IHS

作者：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来测试一下不同的组合看看（录制一个打开首页就可以了），下面是我的测试数据：

数据显示，这还不是一点点提升，竟然快接近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

posted @ 2007-12-13 14:19 tacy lee 阅读(5208) | 评论 (7) | 编辑 收藏

谁在使用这个端口？

作者：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 

posted @ 2007-12-12 17:01 tacy lee 阅读(1494) | 评论 (10) | 编辑 收藏

unix启动过程中sendmail长时间等待问题解决

作者：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，刷一下就启动了，呵呵

回头想想，问题其实很简单，但是在网上却没找到什么好的方案，说明都挺懒得，能绕都绕过去了.

posted @ 2007-12-11 15:58 tacy lee 阅读(2529) | 评论 (4) | 编辑 收藏

db2诊断系列之---捕获sql执行情况

作者：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"}'

posted @ 2007-11-25 14:51 tacy lee 阅读(620) | 评论 (0) | 编辑 收藏