zoukankan      html  css  js  c++  java
  • 使用线程统计信息(Thread Statistics)

    可在session log中使用线程统计信息来判断source,target或组的性能瓶颈
    默认情况下,Integration Service在运行session时,使用一个reader thread,一个transformation thread,还有一个writer thread
    如果其中一个thread有非常高的busy percentage,则说明该部分可能有性能上的瓶颈

    session log中提供以下几个线程相关的信息:

      Run time:
        运行时间,即thread运行的总时间

      Idle time:
        空闲时间,即thread运行的空闲时间,它包括了thread等待其他thread处理的时间
        空闲时间包括的是thread被Integration Service锁定的时间,而不是被操作系统锁定的时间

      Busy time:
        工作时间,即工作时间占总运行时间的百分比
        公式:(run time - idle time) / run time X 100
        如果总的运行时间非常短,如60秒以内,则可以忽略,因为这么短的时间不足以判定为性能上的瓶颈

      Thread work time:
        Integration Service处理运行组件所花费的时间
        在session log中,使用如下格式显示,如果组件花费的时间不长,则它是不会出现在session log中的
          Thread work time breakdown:
            <transformation name>: <number> percent
            <transformation name>: <number> percent
            <transformation name>: <number> percent

        如果在session log中,thread没有准确的统计信息,则说明session运行的时间很短,因此在session log中会提示统计信息不准确

    评估性能瓶颈
      使用线程统计信息评估性能瓶颈,主要通过以下几点:
        1 如果reader和writer线程的Busy time是100%,可以考虑在source和target中使用string类型,因为针对非string类型需额外处理
        2 如果某一组件的work time是100%,可以考虑在segment中追加一个分区点
         当向mapping追加一个分区点时,Integration Service会在session运行时增加处理该组件的线程数
         但如果所在机器的内存已达到或者接近满负荷状态,则不要进行该操作
        3 如果一个组件需要比其他组件更多的处理时间,则可考虑为该组件追加一个pass-through partition point

    实例

    当运行session,session log中关于线程相关的信息会像如下:
    
    ***** RUN INFO FOR TGT LOAD ORDER GROUP [1], CONCURRENT SET [1] *****
    Thread [READER_1_1_1] created for [the read stage] of partition point [SQ_two_gig_file_32B_rows] has completed.
        Total Run Time = [505.871140] secs
        Total Idle Time = [457.038313] secs
        Busy Percentage = [9.653215]
    Thread [TRANSF_1_1_1] created for [the transformation stage] of partition point [SQ_two_gig_file_32B_rows] has completed.
        Total Run Time = [506.230461] secs
        Total Idle Time = [1.390318] secs
        Busy Percentage = [99.725359]
        Thread work time breakdown:
            LKP_ADDRESS: 25.000000 percent
            SRT_ADDRESS: 21.551724 percent
            RTR_ZIP_CODE: 53.448276 percent
    Thread [WRITER_1_*_1] created for [the write stage] of partition point [scratch_out_32B] has completed.
        Total Run Time = [507.027212] secs
        Total Idle Time = [384.632435] secs
        Busy Percentage = [24.139686]
    
    log中包含了如下信息:
    1 运行transformation的总体时间是506秒,工作时间是99.7%,可得知transformation thread几乎没有空闲时间,因此可判定transformation是该session的性能瓶颈
    2 reader thread和writer thread的的工作时间分别为9%和24%,可得知空闲的时间占了大部分,因此可判定reader和writter并不存在性能瓶颈
    3 关于判定transformation中是哪个组件导致性能问题,可参考Thread work time breakdown列表,可看到组件RTR_ZIP_CODE的工作时间最高,是53%,因此可针对此组件调
  • 相关阅读:
    Jmeter_远程启动 I
    jmeter(九)逻辑控制器
    Mysql innodb 间隙锁 (转)
    MySQL- InnoDB锁机制
    Innodb间隙锁,细节讲解(转)
    性能测试:压测中TPS上不去的几种原因分析(就是思路要说清楚)
    Redis性能调优
    Redis基础
    VMThread占CPU高基本上是JVM在频繁GC导致,原因基本上是冰法下短时间内创建了大量对象堆积造成频繁GC。
    关于Hibernate二级缓存第三方插件EHCache缓存
  • 原文地址:https://www.cnblogs.com/shiliye/p/10592666.html
Copyright © 2011-2022 走看看