Re: v7.1b4 bad performance

On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:

I just done the experiment with increasing HZ to 1000 on my own machine
(PII 374). Your test program reports 2 ms instead of 20. The other side
of increasing HZ is surely more overhead to scheduler system. Anyway, it's
a bit of data to dig into, I suppose ;-)

Results for pgbench with 7.1b4: (BTW, machine is FreeBSD 4-stable on IBM
DTLA IDE in ATA66 mode with tag queueing and soft updates turned on)

>> default delay (5 us)

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

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

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

>> delay of 0

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

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

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

Results are very close... Another thing to dig into.

BTW, postgres parameters were: -B 256 -F -i -S

DM> BTW, for modern versions of FreeBSD kernels, there is HZ kernel option
DM> which describes maximum timeslice granularity (actually, HZ value is
DM> number of timeslice periods per second, with default of 100 = 10 ms). On
DM> modern CPUs HZ may be increased to at least 1000, and sometimes even to
DM> 5000 (unfortunately, I haven't test platform by hand).
DM>
DM> So, maybe you can test select granularity at ./configure phase and then
DM> define default commit_delay accordingly.
DM>
DM> Your thoughts?
DM>
DM> Sincerely,
DM> D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
DM> ------------------------------------------------------------------------
DM> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck(at)rinet(dot)ru ***
DM> ------------------------------------------------------------------------
DM>

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