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, you
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 represent
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, 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 a
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-u
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 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
cor
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
> t
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 cyc
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
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 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
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 loo
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 decidi
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 d
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
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.
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 repor
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 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
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? Lookin
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,
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 ve
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 w
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 C
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.
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
27 matches
Mail list logo
