Re: Performance! [SOLVED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Phillip N. wrote: El vie, 11-01-2008 a las 18:15 +0100, Kris Kennaway escribió: Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 Hi. May i ask what kind of hardware is running this test? Just wanted to compare with this AMDX2 4600+ 2G DDR800 box wich gives: 1 500 2 887 4 880 6 834 8 791 thanks! HP ProLiant DL380G5, 2 x X5450 CPUs, 15k SAS HDD, 8G RAM, see the top of the thread. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHlFRexJBWvpalMpkRAlC6AKCZmWSF+TEiIfOTIbC2S6/Ak3DlsACgoZ6i 2NLhlPSCDoAz+74CuWerLw0= =Q8Z1 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
El vie, 11-01-2008 a las 18:15 +0100, Kris Kennaway escribió: Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 Hi. May i ask what kind of hardware is running this test? Just wanted to compare with this AMDX2 4600+ 2G DDR800 box wich gives: 1 500 2 887 4 880 6 834 8 791 thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
Krassimir Slavchev wrote: I have read all related threads about performance problems with multi core systems but still have no idea what to do to make thinks better. Below are results of testing postgresql on HP DL380G5 using sysbench. The results are comparable to: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 but the same tests running on the same hardware using Linux (kernel 2.6.18-53.1.4.el5 SMP x86_64) are very different. PostgreSQL is tuned equal. Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
I have read all related threads about performance problems with multi core systems but still have no idea what to do to make thinks better. Below are results of testing postgresql on HP DL380G5 using sysbench. The results are comparable to: http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 but the same tests running on the same hardware using Linux (kernel 2.6.18-53.1.4.el5 SMP x86_64) are very different. PostgreSQL is tuned equal. Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) Thank you so much! (both of you and those who helped along the way) :-) On monday I will start testing a setup where we are moving from four 10K rpm sas disk in raid 1+0 to eight 15K rpm sas disks in raid 1+0 as well. The former is a ciss p400 controller with 512 MB bbc and the latter is a p800 with 512 MB bbc and an external msa-box. I will test with 7.0 and postgresql 8.2 from ports. Should I test with stable or release? Are there any patches I can apply? Our current db-server is a DL380 G5 woodcrest at 3 Ghz and my test-server will be a 8-core DL360 G5 at 2.4 Ghz (I think). I will log the queries from our live-server and repeat them on the test-server, use pgbench on FreeBSD, Solaris and Linux. I was getting a bit worried when the number varied so much between Linux and FreeBSD. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
On Fri, 11 Jan 2008 18:15:08 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threads transactions/sec 1 755 8 7129 406580 100 6768 compared to Linux: Linux (2.6.18) #threads#transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads#transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) That's great news! Even greater if you consider that not a single line of code inside FreeBSD had to be changed. -- Ricardo Nabinger Sanchez [EMAIL PROTECTED] Powered by FreeBSD http://rnsanchez.wait4.org Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
At 12:15 PM 1/11/2008, Kris Kennaway wrote: Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Thats great news! Just for the record, for build options are there any other options that need to be set other than # diff -u Makefile.default Makefile --- Makefile.default2008-01-11 20:13:06.0 -0500 +++ Makefile2008-01-11 20:16:02.0 -0500 @@ -87,7 +87,7 @@ OPTIONS+= HEIMDAL_KRB5 Builds with Heimdal kerberos support off OPTIONS+= OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) off OPTIONS+= LIBC_R Link w/ libc_r, used by plpython (server) off -OPTIONS+= THREADSAFE make libpq thread safe off +OPTIONS+= THREADSAFE make libpq thread safe on # to run regression tests: OPTIONS+= TESTS Allows the use of a \check\ target (server) off OPTIONS+= DEBUG Builds with debugging symbols off ? In terms of the kernel was this with ULE or SCHED_4BSD ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
Mike Tancsa wrote: At 12:15 PM 1/11/2008, Kris Kennaway wrote: Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host= in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Thats great news! Just for the record, for build options are there any other options that need to be set other than # diff -u Makefile.default Makefile --- Makefile.default2008-01-11 20:13:06.0 -0500 +++ Makefile2008-01-11 20:16:02.0 -0500 @@ -87,7 +87,7 @@ OPTIONS+= HEIMDAL_KRB5 Builds with Heimdal kerberos support off OPTIONS+= OPTIMIZED_CFLAGS Builds with compiler optimizations (-O3) off OPTIONS+= LIBC_R Link w/ libc_r, used by plpython (server) off -OPTIONS+= THREADSAFE make libpq thread safe off +OPTIONS+= THREADSAFE make libpq thread safe on # to run regression tests: OPTIONS+= TESTS Allows the use of a \check\ target (server) off OPTIONS+= DEBUG Builds with debugging symbols off That is necessary for the sysbench client, which is threaded. I don't know if there are any implications for non-threaded applications, but I would hope not. This was with the ULE scheduler, which is basically mandatory for good performance on SMP systems. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
