On Sun, 2004-12-12 at 06:13, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
I never vacuum during the test. Is it possible that all the updates
and inserts would affect this?
That's bad; first because it possibly *is* hurting performance, and
second because if it isn't, your results
Mark Wong [EMAIL PROTECTED] writes:
I never vacuum during the test. Is it possible that all the updates
and inserts would affect this?
That's bad; first because it possibly *is* hurting performance, and
second because if it isn't, your results could legitimately be attacked
as not representing
On Mon, Dec 06, 2004 at 07:52:37PM +, Simon Riggs wrote:
Varying bgwriter_maxpages upwards should take performance higher.
I have 2 runs now. I for both tests, I have bgwriter_percent=100,
checkpoint_segments=8192, checkpoint_timout=600,
debug_shared_buffers=10, log_min_messages=debug1
On Tue, Dec 07, 2004 at 09:12:18AM +, Simon Riggs wrote:
Not sure, as yet, what is causing effect 2. It's not related to the
kernel, but is related to user CPU and I/O waits and effects all tables
in proportion to their overall I/O usage. Some evidence that it becomes
more pronounced as
On Mon, 2004-12-06 at 23:54, Mark Wong wrote:
On Mon, Dec 06, 2004 at 11:44:22PM +, Simon Riggs wrote:
On the graphs... why do the graphs for Proc Utilisation, Index Scans
etc, only show first 300 secs of a 3600 sec long run? Are those axes
correct? (I understand seeing the ramp-up is
On Tue, Nov 30, 2004 at 10:51:42PM +, Simon Riggs wrote:
My suggestion: increase checkpoint_timeout to 600 secs, increase
bgwriter parameters also, to reduce how frequently it is called, as well
as increase the number of blocks per cycle.
Ok, here are a series of three tests varying the
Mark,
Ok, here are a series of three tests varying the bgwriter_delay at 1,
50, and 100:
http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/
Hmmm. Looks inconclusive. The differences between the runs are 0.3%,
which is a margin of error by anyone's definition.
On Mon, 2004-12-06 at 17:43, Josh Berkus wrote:
Mark,
Ok, here are a series of three tests varying the bgwriter_delay at 1,
50, and 100:
http://www.osdl.org/projects/dbt2dev/results/pgsql/bgwriter_delay/
Hmmm. Looks inconclusive. The differences between the runs are 0.3%,
On Mon, 2004-12-06 at 17:42, Mark Wong wrote:
On Tue, Nov 30, 2004 at 10:51:42PM +, Simon Riggs wrote:
My suggestion: increase checkpoint_timeout to 600 secs, increase
bgwriter parameters also, to reduce how frequently it is called, as well
as increase the number of blocks per cycle.
On Mon, Dec 06, 2004 at 09:28:15PM +, Simon Riggs wrote:
Mark,
Few questions:
- can we put the logging to DEBUG1 please, so we can see the
checkpoints? ...and set debug_shared_buffers = 10
Ok, will do.
I don't understand why the checkpoints are so regular at 300 seconds if
the
On Mon, 2004-12-06 at 23:18, Mark Wong wrote:
On Mon, Dec 06, 2004 at 09:28:15PM +, Simon Riggs wrote:
Mark,
Few questions:
Thanks.
On the graphs... why do the graphs for Proc Utilisation, Index Scans
etc, only show first 300 secs of a 3600 sec long run? Are those axes
correct? (I
On Mon, Dec 06, 2004 at 11:44:22PM +, Simon Riggs wrote:
On the graphs... why do the graphs for Proc Utilisation, Index Scans
etc, only show first 300 secs of a 3600 sec long run? Are those axes
correct? (I understand seeing the ramp-up is important, I just want to
check the time axis).
On Tue, Nov 30, 2004 at 07:12:10AM +, Simon Riggs wrote:
If you look at the graph of New Order response time distribution, the
higher result gives much more frequent sub-second response for 8.0beta5
and the hump at around 23secs has moved down to 14secs. Notably, the
payment transaction
Tom,
I do have bgwriter_delay increased to 10, per previous
recommendation, which did smooth out the throughput graph
considerably. I can continue to adjust those settings.
Please try a variety of settings and post your results. It would give
us some hard data to help in deciding what
On Tue, 2004-11-30 at 04:35, Tom Lane wrote:
Mark Wong [EMAIL PROTECTED] writes:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput.
Between beta4 and beta5? That's astonishing. We didn't really do very
much
15 matches
Mail list logo
