Re: Changing the default configuration

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: scott(dot)marlowe(at)ihs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Changing the default configuration
Date: 2003-02-12 02:00:00
Message-ID: 20030212.110000.97298009.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

> > It likely. First you will ran out kernel file descriptors. This could
> > be solved by increasing the kernel table or lowering
> > max_files_per_process, though. Second the total throughput will
> > rapidly descrease if you don't have enough RAM and many
> > CPUs. PostgreSQL can not handle many concurrent
> > connections/transactions effectively. I recommend to employ some kind
> > of connection pooling software and lower the max connections.
>
> Don't know if you saw my other message, but increasing max connects to 200
> used about 10% of all my semaphores and about 10% of my file handles.
> That was while running pgbench to create 200 simo sessions.

I'm not talking about semaphores. You see the low usage of file
descriptors is just because pgbench uses very few tables.

> Keep in mind, on my fairly small intranet database server, I routinely
> have >32 connections, most coming from outside my webserver. Probably no
> more than 4 or 5 connects at a time come from there. These are all things
> like Windows boxes with ODBC running access or something similar. Many of
> the connections are idle 98% of the time, and use little or no real
> resources, even getting swapped out should the server need the spare
> memory (it doesn't :-) that machine is set to 120 max simos if I remember
> correctly.
>
> while 200 may seem high, 32 definitely seems low. So, what IS a good
> compromise? for this and ALL the other settings that should probably be a
> bit higher. I'm guessing sort_mem or 4 or 8 meg hits the knee for most
> folks, and the max fsm settings tom has suggested make sense.

32 is not too low if the kernel file descriptors is not
increased. Beware that running out of the kernel file descriptors is a
serious problem for the entire system, not only for PostgreSQL.

> What wal_sync method should we make default? Or should we pick one based
> on the OS the user is running?

It's really depending on the OS or kernel version. I saw open_sync is
best for certain version of Linux kernel, while fdatasync is good for
another version of kernel. I'm not sure, but it could be possible that
the file system type might affect the wal_sync choice.
--
Tatsuo Ishii

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-02-12 02:42:42 Re: [HACKERS] PostgreSQL Benchmarks
Previous Message Bruno Wolff III 2003-02-12 01:37:48 Re: [HACKERS] Changing the default configuration (was Re:

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-02-12 02:17:45 Re: PGP signing release
Previous Message Lamar Owen 2003-02-12 01:56:56 Contract Programmer Advice.

Browse pgsql-performance by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-02-12 02:42:42 Re: [HACKERS] PostgreSQL Benchmarks
Previous Message Bruno Wolff III 2003-02-12 01:37:48 Re: [HACKERS] Changing the default configuration (was Re: