Re: Performance! [SOLVED]
Kris Kennaway
>>
>> 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:
#threads transactions/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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Claus Guttesen
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
Ricardo Nabinger Sanchez
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 rnsa...@wait4.org
Powered by FreeBSD http://rnsanchez.wait4.org
"Left to themselves, things tend to go from bad to worse."
Mike Tancsa
>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.default 2008-01-11 20:13:06.000000000 -0500
+++ Makefile 2008-01-11 20:16:02.000000000 -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
Kris Kennaway
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