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).
Greg Stark [EMAIL PROTECTED] writes:
Mark Wong [EMAIL PROTECTED] writes:
I have some initial results using 8.0beta5 with our OLTP workload.
http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/
throughput: 4076.97
Do people really only look at the throughput numbers? Looking at those
On Mon, 2004-11-29 at 16:01 -0800, Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search
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
On Tue, Nov 30, 2004 at 08:34:20AM +0100, Michael Paesold wrote:
Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
On Tue, Nov 30, 2004 at 10:57:02AM -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Mark Wong [EMAIL PROTECTED] writes:
I have some initial results using 8.0beta5 with our OLTP workload.
http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/
throughput: 4076.97
Do
On Tue, Nov 30, 2004 at 11:03:03AM -0500, Rod Taylor wrote:
On Mon, 2004-11-29 at 16:01 -0800, Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in
Mark Wong [EMAIL PROTECTED] writes:
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
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, Nov 30, 2004 at 02:00:29AM -0500, Greg Stark wrote:
Mark Wong [EMAIL PROTECTED] writes:
I have some initial results using 8.0beta5 with our OLTP workload.
http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/
throughput: 4076.97
Do people really only look at the
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
Also, I have libc with
Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
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 that was performance-focused. Digging in the CVS
Mark Wong [EMAIL PROTECTED] writes:
I have some initial results using 8.0beta5 with our OLTP workload.
http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/
throughput: 4076.97
Do people really only look at the throughput numbers? Looking at those
graphs it seems that while
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
Mark Wong wrote:
I have some initial results using 8.0beta5 with our OLTP workload.
Off the bat I see about a 23% improvement in overall throughput. The
most significant thing I've noticed was in the oprofile report where
FunctionCall2 and hash_seq_search have moved down the profile a bit.
Also,
27 matches
Mail list logo