Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jan 2008 18:35:11 +0100
From:      "Claus Guttesen" <kometen@gmail.com>
To:        "Kris Kennaway" <kris@freebsd.org>
Cc:        FreeBSD <freebsd-stable@freebsd.org>
Subject:   Re: Performance! [SOLVED]
Message-ID:  <b41c75520801110935v12452116gb816b68752d41dce@mail.gmail.com>
In-Reply-To: <4787A41C.70100@FreeBSD.org>
References:  <476A5EE1.9000003@bulinfo.net> <476FF662.6050604@FreeBSD.org> <477BB7C0.3060603@bulinfo.net> <4787A41C.70100@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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 :)

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b41c75520801110935v12452116gb816b68752d41dce>