Re: Solaris source code

On Mon, Jul 09, 2001 at 02:03:16PM -0700, Nathan Myers allegedly wrote:
> On Mon, Jul 09, 2001 at 02:24:17PM +0200, Mathijs Brands wrote:
> > On Thu, Jul 05, 2001 at 02:03:31PM -0700, Naomi Walker allegedly wrote:
> > > At 04:30 PM 7/5/01 -0400, Bruce Momjian wrote:
> > > >I have purchased the Solaris source code from Sun for $80.  (I could
> > > >have downloaded it for free after faxing them an 11 page contract, but I
> > > >decided I wanted the CD's.)  See the slashdot story at:
> > > >
> > > >         http://slashdot.org/article.pl?sid=01/06/30/1224257&mode=thread
> > > >
> > > >My hope is that I can use the source code to help debug Solaris
> > > >PostgreSQL problems.  It includes source for the kernel and all user
> > > >programs. The code is similar to *BSD kernels.  It is basically Unix
> > > >SvR4 with Sun's enhancements.  It has both AT&T and Sun copyrights on
> > > >the files.
> > > 
> > > Bruce,
> > > 
> > > We are about to roll out PostgreSQL on Solaris, and I am interested in any 
> > > Solaris specific gotcha's.  Do you have some specifics in mind, or was this 
> > > just general preventive maintenance type steps?
> > 
> > PostgreSQL 7.1 fails the regression tests when using a UNIX socket,
> > which is faster than a TCP/IP socket (when both the client and the
> > server are running on the same machine). 
> 
> Have you tried increasing the argument to listen in libpq/pgcomm.c
> from SOMAXCONN to 1024?  I think many people would be very interested
> in your results.

OK, I tried using 1024 (and later 128) instead of SOMAXCONN (defined to
be 5 on Solaris) in src/backend/libpq/pqcomm.c and ran a few regression
tests on two different Sparc boxes (Solaris 7 and 8). The regression
test still fails, but for a different reason. The abstime test fails;
not only on Solaris but also on FreeBSD (4.3-RELEASE).

*** ./expected/abstime.out  Thu May  3 21:00:37 2001
--- ./results/abstime.out Tue Jul 10 10:34:18 2001
***************
*** 47,56 ****      | Sun Jan 14 03:14:21 1973 PST      | Mon May 01 00:30:30 1995 PDT      | epoch
-      | current      | -infinity      | Sat May 10 23:59:12 1947 PST
! (6 rows)
 SELECT '' AS six, ABSTIME_TBL.*    WHERE ABSTIME_TBL.f1 > abstime '-infinity';
--- 47,55 ----      | Sun Jan 14 03:14:21 1973 PST      | Mon May 01 00:30:30 1995 PDT      | epoch      | -infinity
 | Sat May 10 23:59:12 1947 PST
 
! (5 rows)
 SELECT '' AS six, ABSTIME_TBL.*    WHERE ABSTIME_TBL.f1 > abstime '-infinity';

======================================================================

I've checked the FreeBSD and Linux headers and they've got SOMAXCONN set
to 128.

Here's a snippet from the linux listen(2) manpage:

BUGS      If the socket is of type AF_INET, and the backlog argument      is greater than the constant SOMAXCONN (128
inLinux 2.0 &      2.2), it is silently truncated to SOMAXCONN.   Don't  rely      on this value in portable
applicationssince BSD (and some      BSD-derived systems) limit the backlog to 5.
 

I've checked Solaris 2.6, 7 and 8 and the kernels have a default value
of 128 for the number of backlog connections. This number can be
increased to 1000 (maybe even larger). On Solaris 2.4 and 2.5 it is
appearently set to 32. Judging from Adrian Cockcrofts Solaris tuning
guide Sun has been using a default value of 128 from Solaris 2.5.1
on. You do need some patches for 2.5.1: patches 103582 & 103630 (SPARC)
or patches 103581 & 10361 (X86). Later versions of Solaris don't need
any patches. You can check (and set) the number of backlog connections
by using the following command:

Solaris 2.3, 2.4, 2.5 and unpatched 2.5.1: /usr/sbin/ndd /dev/tcp tcp_conn_req_max (untested)

Solaris 2.5.1 (patched), 2.6, 7 and 8: /usr/sbin/ndd /dev/tcp tcp_conn_req_max_q

It'd probably be a good idea to use a value of 128 for the number of
backlog connections and not SOMAXCONN. If the requested number of
backlog connections is bigger than the number the kernel allows, it
should be truncated. Of course, there's no guarantee that this won't
cause problems on arcane platforms such as Ultrix (if it is still
supported).

The Apache survival guide has more info on TCP/IP tuning for several
platforms and includes information on the listen backlog.

Cheers,

Mathijs

Ps. Just checking IRIX 6.5 - it's got the backlog set to 1000
connctions.
-- 
And the beast shall be made legion. Its numbers shall be increased a
thousand thousand fold. The din of a million keyboards like unto a great
storm shall cover the earth, and the followers of Mammon shall tremble.