Re: shared-memory based stats collector - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: shared-memory based stats collector
Date
Msg-id 20190710.133552.205551382.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: shared-memory based stats collector  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: shared-memory based stats collector
List pgsql-hackers
At Thu, 04 Jul 2019 19:27:54 +0900 (Tokyo Standard Time), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
<20190704.192754.27063464.horikyota.ntt@gmail.com>
>     #db  #tbl  #clients  #iter  #xactlen #referers
> A1:   1     1         1  20000        10        0
> A2:   1     1         1  20000        10        1
> B1:   1     1        90   2000        10        0
> B2:   1     1        90   2000        10        1
> C1:   1    50        90   2000        10        0
> C2:   1    50        90   2000        10        1
> D1:  50     1        90   2000        10        0
> D2:  50     1        90   2000        10        1
> E1:  50     1        90   2000        10       10
> F1:  50     1        10   2000        10       90
> 
> 
> 
>                 master                               patched
>         updator       referrer               updator       referrer       
>        time / stdev  count / stdev          time / stdev   count / stdev    
> A1: 1769.13 / 71.87                      1729.97 / 61.58
> A2: 1903.94 / 75.65  2906.67 /  78.28    1849.41 / 43.00  2855.33 /  62.95
> B1: 2967.84 /  9.88                      2984.20 /  6.10
> B2: 3005.38 /  5.32   253.00 /  33.09    3007.26 /  5.70   253.33 /  60.63
> C1: 3066.14 / 13.80                      3069.34 / 11.65
> C2: 3353.66 /  8.14   282.92 /  20.65    3341.36 / 12.44   251.65 /  21.13
> D1: 2977.12 /  5.12                      2991.60 /  6.68
> D2: 3005.80 /  6.44   252.50 /  38.34    3010.58 /  7.34   282.33 /  57.07
> E1: 3255.47 /  8.91   244.02 /  17.03    3293.88 / 18.05   249.13 /  14.58
> F1: 2620.85 /  9.17   202.46 /   3.35    2668.60 / 41.04   208.19 /   6.79
> 
> 
> ratio (100: same, smaller value means patched version is faster)
> 
>           updator          referrer
>      patched/master(%)    master/patched (%)
> A1:          97.79            -
> A2:          97.14          101.80
> B1:         100.55
> B2:         100.06           99.87
> C1:         100.10
> C2:          99.63          112.43
> D1:         100.49
> D2:         100.16           89.43
> E1:         101.18           97.95
> F1:         101.82           97.25
> 
> 
> Mmm... I don't see distinctive tendency.. Referrer side shows
> larger fluctuation but I'm not sure that suggests something
> meaningful.
> 
> I'll rerun the bencmarks with loger period (many itererations).

I put more puressure to the system.

G1: 1 db, 400 clients, 1000 tables, 20000 loops/client, 1000 query/tr, 0 reader
G2: 1 db, 400 clients, 1000 tables, 20000 loops/client, 1000 query/tr, 1 reader


Result:
                master                               patched
           updator        referrer               updator       referrer       
         time / stdev   count / stdev          time / stdev   count / stdev    
G1: 125946.22 / 796.83                    125227.24 / 89.82
G2: 126463.47 / 81.87 1985.70 /  33.96    125427.95 / 82.35 1985.60 /  55.24

Ratio: (100: same, smaller value means patched version is faster)

          updator          referrer
     patched/master(%)    master/patched (%)
G1:          99.40            -
G2:          99.18          100.0

Slightly faster, or maybe significantly enough considering the
stdev. More crucial difference is shown outside the
numbers. Non-patched version complained that (incorrectly) "stats
collector not respond, used stale stats" many times, which is not
seen on patched version. That means that the reader reads older
numbers as far as 1 second ago. (It might be good that writer
should complain about update holdoff for more than, say 0.75s.)


CF-bot warned that it doesn't work on Windows. I'm experiencing
an very painful time to wait for tortoise git is walking slowly
as its name suggests. It would be fixed in the next version.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Next
From: Michael Paquier
Date:
Subject: Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11