Обсуждение: Prelimiary DBT-2 Test results
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. -- Mark Wong - - markw@osdl.org Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503) 626-2455 x 32 (office) (503) 626-2436 (fax) http://www.osdl.org/archive/markw/
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 ByeShridhar -- 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, Pennsylvania19073
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