Prelimiary DBT-2 Test results

markw@osdl.org wrote:

http://developer.osdl.org/markw/44/

I threw together (kind of sloppily) a web page of the data I was
starting to collect for our DBT-2 workload (TPC-C derivative) on
PostgreSQL 7.3.4. Keep in mind not much database tuning has been done
yet. Feel free to ask any questions.

The kernel readprofile output is very odd:
sys_ipc receives lots of hits, but that function is a trivial multiplexer.
sys_timedsemop, and try_atomic_semop got 0 hits - that's the main
implementation of sysv semaphores. Could you double check your
readprofile scripts?

--
Manfred

On 4 Sep 2003 at 10:53, markw@osdl.org wrote:

http://developer.osdl.org/markw/44/

I threw together (kind of sloppily) a web page of the data I was
starting to collect for our DBT-2 workload (TPC-C derivative) on
PostgreSQL 7.3.4. Keep in mind not much database tuning has been done
yet. Feel free to ask any questions.

You should set effective cache size to bit more realistic than 1000. That's
just 8MB.

I would also suggest you setting autocommit to off, in case that makes any
difference. If the application is entirely managing it's own transactions
explicitly this should not make any difference.

If youhave good disks like SCSI/IDE RAID or above, you can reduce
random_page_cost to 2 or even less.

For heavily updated systems, you should have WAL buffers bit more. I don't know
exact imact of that setting though. You could try 32/64/128. On the same note,
if you are getting checkpoints too frequently, you can try increasing
checkpoint segments. The logs will tell as such.

HTH

Bye
Shridhar

--
QOTD: "When she hauled ass, it took three trips."

Shridhar Daithankar wrote:

For heavily updated systems, you should have WAL buffers bit more. I don't know
exact imact of that setting though. You could try 32/64/128. On the same note,
if you are getting checkpoints too frequently, you can try increasing
checkpoint segments. The logs will tell as such.

Only 7.4beta reports if checkpoints are too frequent.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On 4 Sep, Manfred Spraul wrote:

markw@osdl.org wrote:

http://developer.osdl.org/markw/44/

I threw together (kind of sloppily) a web page of the data I was
starting to collect for our DBT-2 workload (TPC-C derivative) on
PostgreSQL 7.3.4. Keep in mind not much database tuning has been done
yet. Feel free to ask any questions.

The kernel readprofile output is very odd:
sys_ipc receives lots of hits, but that function is a trivial multiplexer.
sys_timedsemop, and try_atomic_semop got 0 hits - that's the main
implementation of sysv semaphores. Could you double check your
readprofile scripts?

It looks like I have the system.map correct. I'll certainly keep my
eyes open and ask around, but seeing poll_idle and schedule on top seem
to suggest it's ok.

Another question:
Is it possible to apply patches to postgresql before a DBT-2 run, or is
only patching the kernel supported?

--
Manfred

On 6 Sep, Manfred Spraul wrote:

Another question:
Is it possible to apply patches to postgresql before a DBT-2 run, or is
only patching the kernel supported?

The data I reported is from a test system I'm using in our lab, so I
can certainly try patches. The current state of STP only allows patches
to the kernel, but we're moving in a direction so that other components,
like PostgreSQL can also be patched. There is also another option. You
can request hardware resources here at the OSDL and get remote access,
and we'd be glad to help out set up our workload, if you want to base
your tests with it. If that's something you would be interested in all
you have to do is sign up as an associate of the OSDL (free):

http://www.osdl.org/lab_activities/be_an_associate.html

and propose a project:

http://www.osdl.org/lab_activities/lab_projects/propose_a_project.html

Mark

On 4 Sep, Manfred Spraul wrote:

markw@osdl.org wrote:

http://developer.osdl.org/markw/44/

I threw together (kind of sloppily) a web page of the data I was
starting to collect for our DBT-2 workload (TPC-C derivative) on
PostgreSQL 7.3.4. Keep in mind not much database tuning has been done
yet. Feel free to ask any questions.

The kernel readprofile output is very odd:
sys_ipc receives lots of hits, but that function is a trivial multiplexer.
sys_timedsemop, and try_atomic_semop got 0 hits - that's the main
implementation of sysv semaphores. Could you double check your
readprofile scripts?

Someone here was kind enough to run a little test comparing profiles
from 2.4.20-19 (a redhat kernel) and 2.6.0-test4-mm5. He found that the
2.6.0-test4-mm5 profile lacked sys_timedsemop and try_atomic_semop.

Mark

On Fri, 2003-09-05 at 15:16, Manfred Spraul wrote:

Another question:
Is it possible to apply patches to postgresql before a DBT-2 run, or is
only patching the kernel supported?

--
Manfred

As Mark indicated, we currently only support kernel patches via our PLM
system, but we are in the process of changing that for other components
(e.g. the compilers, the statistics tools). Ultimately anything we can
save as source code, we will be able to patch and accessible via our
test platform, Scalable Test Platform (STP).

If we were to make it possible to download PostgreSQL releases on PLM
and allow developers to apply patches to it, would there be interest
from the community in that capability?

In other words, would you all use it to test compiles on various
hardware (I32, I64, PowerPC), or test PostgreSQL on various Linux
kernels?

Would you run the patches against the database test we have via STP?

Is there any other feature you might suggest?

--
Mary Edie Meredith <maryedie@osdl.org>
Open Source Development Lab