• PostgreSQL数据库pg_test_timing学习使用


    pg_test_timing 是什么

    pg_test_timing 是postgresql数据库提供的一个工具,用来评测操作系统计时效率和开销的,简单的说就是gettimeofday (操作系统方法)返回快慢。

    pg_test_timing 使用的原因

    目前知道的一个原因是,查看度量SQL执行时间经常使用两种方法 iming SQL 和 explain analyze SQL。但是通常 explain analyze SQL 统计的执行时间长,有些机器长很多。为什么呢,其中一个原因是explain analyze SQL 会为执行的每一个步骤添加计时信息,会有计时的开销。对于计时效率比较差的机器,explain analyze SQL 统计的执行时间就会偏离实际时间很多。下面的例子explain analyze 比 iming 多了5600ms !

    例如:

    znspgl=# explain analyze select count(*) from  (select distinct(c_bh_aj)  from db_znspgl.t_zlglpt_wt where d_cjrq between '20160913' and '20170909' ) t;
                                                                                 QUERY PLAN                                       
    
    ------------------------------------------------------------------------------------------------------------------------------
     Aggregate  (cost=347567.23..347567.24 rows=1 width=0) (actual time=6954.845..6954.846 rows=1 loops=1)
       ->  Unique  (cost=0.56..343310.31 rows=340554 width=33) (actual time=0.034..5969.209 rows=1322165 loops=1)
             ->  Index Only Scan using i_zlglpt_wt_zh01 on t_zlglpt_wt  (cost=0.56..336784.36 rows=2610380 width=33) (actual time=
    0.031..2840.502 rows=2644330 loops=1)
                   Index Cond: ((d_cjrq >= '2016-09-13'::date) AND (d_cjrq <= '2017-09-09'::date))
                   Heap Fetches: 0
     Planning time: 0.172 ms
     Execution time: 6954.890 ms
    (7 rows)
    
    
    znspgl=# 	iming on
    Timing is on.
    znspgl=#  select count(*) from  (select distinct(c_bh_aj)  from db_znspgl.t_zlglpt_wt where d_cjrq between '20160913' and '20170909' ) t;
      count  
    ---------
     1322165
    (1 row)
    
    Time: 1322.715 ms
    
    

    pg_test_timing 如何使用

    pg_test_timing 位于PostgresSQL的安装目录下/bin 目录中,即$PGHOME/bin/pg_test_timing。和其他的linux命令使用方法一样,pg_test_timing --help可以查看用法。

    • 示例1:
    [thunisoft@bogon ~]$ pg_test_timing
    Testing timing overhead for 3 seconds.
    Per loop time including overhead: 22.37 nsec
    Histogram of timing durations:
    < usec   % of total      count
         1     97.77008  131116962
         2      2.22722    2986862
         4      0.00217       2910
         8      0.00004         55
        16      0.00048        644
        32      0.00001         18
        64      0.00000          3
       128      0.00000          2
    
    
    • 示例2:
    [thunisoft@localhost ~]$ pg_test_timing
    Testing timing overhead for 3 seconds.
    Per loop time including overhead: 63.10 nsec
    Histogram of timing durations:
    < usec   % of total      count
         1     93.92173   44651011
         2      6.06895    2885219
         4      0.00044        209
         8      0.00096        455
        16      0.00294       1398
        32      0.00393       1867
        64      0.00036        169
       128      0.00031        145
       256      0.00035        166
       512      0.00004         18
      1024      0.00000          2
      2048      0.00000          1
    
    

    pg_test_timing 结果如何评判

    首先,看Per loop time including overhead(平均每次循环开销)。

    示例1的平均每次循环开销 为22纳秒
    示例2的平均每次循环开销 为63纳秒

    其次,看柱状图统计。

    示例1,显示97%的循环在1微秒(100纳秒)内完成
    示例2,显示93%的循环在1微秒(100纳秒)内完成

    好的机器应该显示90%的调用都在1微秒(100纳秒)内完成

  • 相关阅读:
    怎么自定义修改CnBlogs博客园主题模板css样式
    前端怎么避免无效的请求,减轻服务器负载
    360浏览器奇葩问题:非得打开一次控制台才能登录(try catch finally 用法)
    react中<br/>不换行、多个&nbsp;只显示一个空格的问题 dangerouslySetInnerHTML
    webpack压缩文件错误:ERROR in bundle.js from UglifyJs
    webpack css单独打包 及extract-text-webpack-plugin插件
    css如何引入第三方字体
    计数排序
    接口
    抽象方法和抽象类
  • 原文地址:https://www.cnblogs.com/wangzhen3798/p/7630600.html
Copyright © 2020-2023  润新知