Re: [ADMIN] v7.1b4 bad performance - Mailing list pgsql-hackers
From | Dmitry Morozovsky |
---|---|
Subject | Re: [ADMIN] v7.1b4 bad performance |
Date | |
Msg-id | Pine.BSF.4.21.0102182245320.16523-100000@woozle.rinet.ru Whole thread Raw |
In response to | Re: [ADMIN] v7.1b4 bad performance (Dmitry Morozovsky <marck@rinet.ru>) |
List | pgsql-hackers |
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@rinet.ru *** DM> ------------------------------------------------------------------------ DM> Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
pgsql-hackers by date: