Performance! [SOLVED]
Kris Kennaway
kris at FreeBSD.org
Fri Jan 11 17:35:29 PST 2008
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.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
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
More information about the freebsd-stable
mailing list