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