Re: [PERFORM] Solaris Performance (Again)
yes - originally I was going to stop at 8 clients, but once the bit was between the teethIf I get another box to myself I will try -s 50 or 100 and see what that shows up. cheers Mark Neil Conway wrote: FYI, the pgbench docs state: NOTE: scaling factor should be at least as large as the largest number of clients you intend to test; else you'll mostly be measuring update contention. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] Solaris Performance (Again)
Good point - It is Pg 7.4beta1 , compiled with CFLAGS += -O2 -funroll-loops -fexpensive-optimizations Jeff wrote: What version of PG? If it is before 7.4 PG compiles with _NO_ optimization by default and was a huge part of the slowness of PG on solaris. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Solaris Performance (Again)
Mark Kirkwood <[EMAIL PROTECTED]> writes: > Note : The Pgbench runs were conducted using -s 10 and -t 1000 -c > 1->64, 2 - 3 runs of each setup were performed (averaged figures > shown). FYI, the pgbench docs state: NOTE: scaling factor should be at least as large as the largest number of clients you intend to test; else you'll mostly be measuring update contention. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] Solaris Performance (Again)
On Wed, 10 Dec 2003 18:56:38 +1300 Mark Kirkwood <[EMAIL PROTECTED]> wrote: > The major performance killer appeared to be mounting the filesystem > with the logging option. The next most significant seemed to be the > choice of sync_method for Pg - the default (open_datasync), which we > initially thought should be the best - appears noticeably slower than > fdatasync. > Some interesting stuff, I'll have to play with it. Currently I'm pleased with my solaris performance. What version of PG? If it is before 7.4 PG compiles with _NO_ optimization by default and was a huge part of the slowness of PG on solaris. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PERFORM] Solaris Performance (Again)
This is a well-worn thread title - apologies, but these results seemed interesting, and hopefully useful in the quest to get better performance on Solaris: I was curious to see if the rather uninspiring pgbench performance obtained from a Sun 280R (see General: ATA Disks and RAID controllers for database servers) could be improved if more time was spent tuning. With the help of a fellow workmate who is a bit of a Solaris guy, we decided to have a go. The major performance killer appeared to be mounting the filesystem with the logging option. The next most significant seemed to be the choice of sync_method for Pg - the default (open_datasync), which we initially thought should be the best - appears noticeably slower than fdatasync. We also tried changing some of the tuneable filesystem options using tunefs - without any measurable effect. Are Pg/Solaris folks running with logging on and sync_method default out there ? - or have most of you been through this already ? Pgbench Results (no. clients and transactions/s ) : Setup 1: filesystem mounted with logging No. tps --- 1 17 2 17 4 22 8 22 16 28 32 32 64 37 Setup 2: filesystem mounted without logging No. tps --- 1 48 2 55 4 57 8 62 16 65 32 82 64 95 Setup 3 : filesystem mounted without logging, Pg sync_method = fdatasync No. tps --- 1 89 2 94 4 95 8 93 16 99 32 115 64 122 Note : The Pgbench runs were conducted using -s 10 and -t 1000 -c 1->64, 2 - 3 runs of each setup were performed (averaged figures shown). Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
