Thread: Request for Benchmarks...
I mentioned this in another message, but I'll reiterate it for everyone's sake. In a day or two, I'll have the chance to pit two machines against each other to test their capacity at serving out queries with Postgres - a dual Athlon MP 1800+ and a quad 700 MHz Xeon, both running Linux. The benchmark I'm planning on running involves a sample of queries taken from our day-to-day production, so that would most likely reflect what *I* can expect out of the machine. However, if anyone is interested, and has any other PG benchmarks on them to get some numbers, feel free to let me know. I'll only have about a day to run all of the benchmarks, so they have to be reasonably-sized. Once I'm done, I'll make a full report. steve
"Steve Wolfe" <steve@iboats.com> writes: > I mentioned this in another message, but I'll reiterate it for > everyone's sake. In a day or two, I'll have the chance to pit two > machines against each other to test their capacity at serving out queries > with Postgres - a dual Athlon MP 1800+ and a quad 700 MHz Xeon, both > running Linux. The benchmark I'm planning on running involves a sample of > queries taken from our day-to-day production, so that would most likely > reflect what *I* can expect out of the machine. You'll want to make sure both machines have comparable disk subsystems; otherwise you won't be comparing what you think you're comparing... -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
Steve Wolfe wrote: > > I mentioned this in another message, but I'll reiterate it for > everyone's sake. In a day or two, I'll have the chance to pit two > machines against each other to test their capacity at serving out queries > with Postgres - a dual Athlon MP 1800+ and a quad 700 MHz Xeon, both > running Linux. The benchmark I'm planning on running involves a sample of > queries taken from our day-to-day production, so that would most likely > reflect what *I* can expect out of the machine. > > However, if anyone is interested, and has any other PG benchmarks on > them to get some numbers, feel free to let me know. I'll only have about > a day to run all of the benchmarks, so they have to be reasonably-sized. > Once I'm done, I'll make a full report. All I can say is make sure you are using 7.2 and not an earlier release, especially for SMP machines, and also look at checkpoint_segments to prevent checkpointing too often under heavy load. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> All I can say is make sure you are using 7.2 and not an earlier release, > especially for SMP machines, and also look at checkpoint_segments to > prevent checkpointing too often under heavy load. Upgrading our production server to a brand-new release, in the middle of the upswing of our season, might not be the smartest thing for me to do, but I'll see if I can. I'm not sure what you mean about checkpoint_segments, can you point me to more information? steve
Steve Wolfe wrote: > > All I can say is make sure you are using 7.2 and not an earlier release, > > especially for SMP machines, and also look at checkpoint_segments to > > prevent checkpointing too often under heavy load. > > Upgrading our production server to a brand-new release, in the middle of > the upswing of our season, might not be the smartest thing for me to do, > but I'll see if I can. I'm not sure what you mean about > checkpoint_segments, can you point me to more information? I am working on an addition to my hardware tuning guide this week for that item. Tom Lane in pgbench testing found that heavy activity was causing checkpoints every few seconds, rather than the usual 1-5 minutes we prefer. The only want to know if you need more segements is to look in the server logs and time the duration between checkpoints. We have a TODO item to improve this reporting in 7.3. You can also add log timestamps to make it easier. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > I mentioned this in another message, but I'll reiterate it for > > everyone's sake. In a day or two, I'll have the chance to pit two > > machines against each other to test their capacity at serving out queries > > with Postgres - a dual Athlon MP 1800+ and a quad 700 MHz Xeon, both > > running Linux. The benchmark I'm planning on running involves a sample of > > queries taken from our day-to-day production, so that would most likely > > reflect what *I* can expect out of the machine. > > You'll want to make sure both machines have comparable disk > subsystems; otherwise you won't be comparing what you think you're > comparing... I plan on making sure that the database is entirely in disk cache, so that the disk subsystem drops out of the picture. steve
Build pgbench in the contrib subdirectory of the source. Run it for a reasonably large number of transactions and numbers of clients from one to N (10, 20, etc). That's a benchmark that anyone else with the source can also build and run. Steve Wolfe wrote: > I mentioned this in another message, but I'll reiterate it for >everyone's sake. In a day or two, I'll have the chance to pit two >machines against each other to test their capacity at serving out queries >with Postgres - a dual Athlon MP 1800+ and a quad 700 MHz Xeon, both >running Linux. The benchmark I'm planning on running involves a sample of >queries taken from our day-to-day production, so that would most likely >reflect what *I* can expect out of the machine. > > However, if anyone is interested, and has any other PG benchmarks on >them to get some numbers, feel free to let me know. I'll only have about >a day to run all of the benchmarks, so they have to be reasonably-sized. >Once I'm done, I'll make a full report. > >