Re: v7.1b4 bad performance

On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:

DM> I just done the experiment with increasing HZ to 1000 on my own machine
DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
DM> a bit of data to dig into, I suppose ;-)
DM>
DM> Results for pgbench with 7.1b4: (BTW, machine is FreeBSD 4-stable on IBM
DM> DTLA IDE in ATA66 mode with tag queueing and soft updates turned on)

Oh, I forgot to paste the results from original system (with HZ=100). Here
they are:

>> delay = 5

number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 47.422866(including connections establishing)
tps = 47.493439(excluding connections establishing)

number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 37.930605(including connections establishing)
tps = 38.308613(excluding connections establishing)

number of clients: 20
number of transactions per client: 50
number of transactions actually processed: 1000/1000
tps = 35.757531(including connections establishing)
tps = 36.420532(excluding connections establishing)

>> delay = 0

number of clients: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
tps = 111.521859(including connections establishing)
tps = 111.904026(excluding connections establishing)

number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 62.808216(including connections establishing)
tps = 63.819590(excluding connections establishing)

number of clients: 20
number of transactions per client: 50
number of transactions actually processed: 1000/1000
tps = 64.250431(including connections establishing)
tps = 66.438067(excluding connections establishing)


So, I suppose (very preliminary, of course ;):

1 -  at least for dedicated PostgreSQL servers it _may_ be
reasonable to increase HZ
2 - there is still no advantages of using delay != 0.

Your ideas?



DM>
DM> >> default delay (5 us)
DM>
DM> number of clients: 1
DM> number of transactions per client: 1000
DM> number of transactions actually processed: 1000/1000
DM> tps = 96.678008(including connections establishing)
DM> tps = 96.982619(excluding connections establishing)
DM>
DM> number of clients: 10
DM> number of transactions per client: 100
DM> number of transactions actually processed: 1000/1000
DM> tps = 77.538398(including connections establishing)
DM> tps = 79.126914(excluding connections establishing)
DM>
DM> number of clients: 20
DM> number of transactions per client: 50
DM> number of transactions actually processed: 1000/1000
DM> tps = 68.448429(including connections establishing)
DM> tps = 70.957500(excluding connections establishing)
DM>
DM> >> delay of 0
DM>
DM> number of clients: 1
DM> number of transactions per client: 1000
DM> number of transactions actually processed: 1000/1000
DM> tps = 111.939751(including connections establishing)
DM> tps = 112.335089(excluding connections establishing)
DM>
DM> number of clients: 10
DM> number of transactions per client: 100
DM> number of transactions actually processed: 1000/1000
DM> tps = 84.262936(including connections establishing)
DM> tps = 86.152702(excluding connections establishing)
DM>
DM> number of clients: 20
DM> number of transactions per client: 50
DM> number of transactions actually processed: 1000/1000
DM> tps = 79.678831(including connections establishing)
DM> tps = 83.106418(excluding connections establishing)
DM>
DM>
DM> Results are very close... Another thing to dig into.
DM>
DM> BTW, postgres parameters were: -B 256 -F -i -S
DM>
DM>
DM>
DM>
DM> DM> BTW, for modern versions of FreeBSD kernels, there is HZ kernel option
DM> DM> which describes maximum timeslice granularity (actually, HZ value is
DM> DM> number of timeslice periods per second, with default of 100 = 10 ms). On
DM> DM> modern CPUs HZ may be increased to at least 1000, and sometimes even to
DM> DM> 5000 (unfortunately, I haven't test platform by hand).
DM> DM>
DM> DM> So, maybe you can test select granularity at ./configure phase and then
DM> DM> define default commit_delay accordingly.
DM> DM>
DM> DM> Your thoughts?
DM> DM>
DM> DM> Sincerely,
DM> DM> D.Marck                                   [DM5020, DM268-RIPE, DM3-RIPN]
DM> DM> ------------------------------------------------------------------------
DM> DM> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
DM> DM> ------------------------------------------------------------------------
DM> DM>
DM>
DM> Sincerely,
DM> D.Marck                                   [DM5020, DM268-RIPE, DM3-RIPN]
DM> ------------------------------------------------------------------------
DM> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
DM> ------------------------------------------------------------------------
DM>
DM>

Sincerely,
D.Marck                                   [DM5020, DM268-RIPE, DM3-RIPN]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------