Thread: continuing daily testing of dbt2 against postgresql
Hi everyone, After over a year of problems (old site http://developer.osdl.org/markw/postgrescvs/) I have resumed producing daily results of dbt-2 against PostgreSQL CVS code with results here:http://dbt.osdl.org/dbt2.html The only really new thing is better described stats on the i/o activity per tablespace. I'm generating iostat plots for devices per tablespace. I'm going to track results at two scale factors,one where the system is not quite overloaded and one where the system is overloaded. I'll have dbt3 results shortly, I hope. Let me know if there are any questions. Regards, Mark
Mark Wong <markw@osdl.org> writes: > After over a year of problems (old site > http://developer.osdl.org/markw/postgrescvs/) I have resumed producing > daily results of dbt-2 against PostgreSQL CVS code with results here: > http://dbt.osdl.org/dbt2.html This is good to hear! I am curious where we are now compared to where we were a year ago ... do you still have the old data, and is the test setup still comparable? regards, tom lane
> Mark Wong <markw@osdl.org> writes: >> After over a year of problems (old site >> http://developer.osdl.org/markw/postgrescvs/) I have resumed producing >> daily results of dbt-2 against PostgreSQL CVS code with results here: >> http://dbt.osdl.org/dbt2.html > > This is good to hear! I am curious where we are now compared to where > we were a year ago ... do you still have the old data, and is the test > setup still comparable? The test setup is on completely different hardware. I still have the old data and it's accessible, but it'll take a little bit of work to regenerate the links. I'll try to work on that. Mark
markw@osdl.org wrote: >> Mark Wong <markw@osdl.org> writes: >>> After over a year of problems (old site >>> http://developer.osdl.org/markw/postgrescvs/) I have resumed producing >>> daily results of dbt-2 against PostgreSQL CVS code with results here: >>> http://dbt.osdl.org/dbt2.html >> This is good to hear! I am curious where we are now compared to where >> we were a year ago ... do you still have the old data, and is the test >> setup still comparable? > > The test setup is on completely different hardware. I still have the old > data and it's accessible, but it'll take a little bit of work to > regenerate the links. I'll try to work on that. I think it would also help if you would create reference runs for the latest 8.0 and 8.1 releases on the new hardware. Best Regards Michael Paesold
Tom Lane wrote: > Mark Wong <markw@osdl.org> writes: >> After over a year of problems (old site >> http://developer.osdl.org/markw/postgrescvs/) I have resumed producing >> daily results of dbt-2 against PostgreSQL CVS code with results here: >> http://dbt.osdl.org/dbt2.html > > This is good to hear! I am curious where we are now compared to where > we were a year ago ... do you still have the old data, and is the test > setup still comparable? I made another couple of gross mistakes of forgetting to compile PostgreSQL with --enable-thread-safe and enabling the user space irq balancing program in Linux. I've restarted the histories with 600 and 800 warehouse runs where 600 should be below peak system performance and 800 pushing the system beyond it's peak performance. Still working on getting pointers to the old data... Regards, Mark
Michael Paesold wrote: > markw@osdl.org wrote: >>> Mark Wong <markw@osdl.org> writes: >>>> After over a year of problems (old site >>>> http://developer.osdl.org/markw/postgrescvs/) I have resumed producing >>>> daily results of dbt-2 against PostgreSQL CVS code with results here: >>>> http://dbt.osdl.org/dbt2.html >>> This is good to hear! I am curious where we are now compared to where >>> we were a year ago ... do you still have the old data, and is the test >>> setup still comparable? >> >> The test setup is on completely different hardware. I still have the old >> data and it's accessible, but it'll take a little bit of work to >> regenerate the links. I'll try to work on that. > > I think it would also help if you would create reference runs for the > latest 8.0 and 8.1 releases on the new hardware. Ok, I'll try to work those in within the next couple days. Regards, Mark
On Sun, Oct 08, 2006 at 05:26:11PM -0700, Mark Wong wrote: > I made another couple of gross mistakes of forgetting to compile > PostgreSQL with --enable-thread-safe and enabling the user space irq > balancing program in Linux. I've restarted the histories with 600 and What's the advantage of irq balancing in user space as opposed to the kernel (which is the default, right?) -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote: > On Sun, Oct 08, 2006 at 05:26:11PM -0700, Mark Wong wrote: >> I made another couple of gross mistakes of forgetting to compile >> PostgreSQL with --enable-thread-safe and enabling the user space irq >> balancing program in Linux. I've restarted the histories with 600 and > > What's the advantage of irq balancing in user space as opposed to the > kernel (which is the default, right?) Linux doesn't have irq balancing in the kernel. They've made the decision to leave that to a user space process. The irq balancing flag in the kernel is just to enable the hooks for a user space program. Mark
On Mon, Oct 09, 2006 at 10:37:32AM -0700, Mark Wong wrote: > Jim C. Nasby wrote: > >On Sun, Oct 08, 2006 at 05:26:11PM -0700, Mark Wong wrote: > >>I made another couple of gross mistakes of forgetting to compile > >>PostgreSQL with --enable-thread-safe and enabling the user space irq > >>balancing program in Linux. I've restarted the histories with 600 and > > > >What's the advantage of irq balancing in user space as opposed to the > >kernel (which is the default, right?) > > Linux doesn't have irq balancing in the kernel. They've made the > decision to leave that to a user space process. The irq balancing flag > in the kernel is just to enable the hooks for a user space program. Oooh, interesting... I wonder how many installs out there are running without IRQ balancing enabled. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Luke Lonergan wrote: > +1 > > Mark, can you quantify the impact of not running with IRQ balancing enabled? Yeah, I'll try to have that done within a couple of days. Mark