Re: shared-memory based stats collector

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: shared-memory based stats collector
Дата
Msg-id 20190710.133552.205551382.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: shared-memory based stats collector  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: shared-memory based stats collector  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11