Re: [HACKERS] PostgreSQL and Solaris 7?

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [HACKERS] PostgreSQL and Solaris 7?
Дата
Msg-id 199902110508.OAA01824@ext16.sra.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] PostgreSQL and Solaris 7?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] PostgreSQL and Solaris 7?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > I checked my Solaris box using sysdef and got:
> 
> >     10  entries in semaphore map (SEMMAP)
> >     10  semaphore identifiers (SEMMNI)
> >     60  semaphores in system (SEMMNS)
> >     25  max semaphores per id (SEMMSL)
> 
> These settings are far too small if you hope to go beyond a couple dozen
> Postgres backends.  Postgres requires one semaphore per backend, which
> it (presently) allocates in groups of 16.  Thus you cannot get past 48
> backends with these kernel settings --- starting the 49th backend requires
> allocating semaphores 49-64, but your system is set up to allow only 60
> semas total.
> 
> (If your platform doesn't have a TEST_AND_SET implementation then
> several more semas are needed for spinlock emulation, but I assume
> that's not a problem on Solaris.)
> 
> SEMMNI should also be bumped up, since you could not get past 10*16
> backends with it set at 10 --- and that's not allowing for anything
> else to be using semaphores!  It'd be foolish not to leave at least
> a couple dozen semas and sema IDs free at Postgres' peak usage.
> 
> I dunno what SEMMAP is (no such parameter in my kernel) but it
> probably needs to be at least as large as SEMMNI, possibly larger.

Ok. If I consider 64 backends, at least following settings would be
required from your suggestion:

64  entries in semaphore map (SEMMAP)
64  semaphore identifiers (SEMMNI)
64  semaphores in system (SEMMNS)
25  max semaphores per id (SEMMSL)

Is this correct?

> To run more than 64 backends you will also need to increase Postgres'
> internal MaxBackendId constant.  Somewhere along here you are also
> likely to run into other kernel configuration limits, like the total
> number of processes, total processes for a single user, total number
> of open files, etc.  These are all fixable but you don't want to
> reboot the system to install new values very often.
> 
> We need a chapter in the installation guide that covers all this stuff
> in more detail... offhand I don't even know how many open files to
> allow per backend.

PostgreSQL seems to eat up file descriptor as many as possible. I
observe 30-40 or more files are opened by a backend. This is
definitelty a problem when thinking about large number of backends.

My solution is using limit or ulimit command to lower the number of
avaliable file descriptors when starting postmaster.  The lowered
number must be 20 or greater, since PostgreSQL's "virtual file
descriptor" system reserves at least 20 open files per
backend(backend/storage/file/fd.c).
---
Tatsuo Ishii


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] cannot cast bpchar and varchar
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] interface libpq Makefile.in patch