RE: [HACKERS] PostgreSQL and Solaris 7?
От | Daryl W. Dunbar |
---|---|
Тема | RE: [HACKERS] PostgreSQL and Solaris 7? |
Дата | |
Msg-id | 00bd01be5520$6ccd9780$1445e59b@ddunbar.eni.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] PostgreSQL and Solaris 7? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
In order to increase the number of semaphores, I added the following entries to /etc/system and rebooted: * * Increase the total number of Semaphores per user and system set semsys:seminfo_semmap=128 set semsys:seminfo_semmni=128 set semsys:seminfo_semmns=8192 set semsys:seminfo_semmnu=8192 set semsys:seminfo_semmsl=64 set semsys:seminfo_semopm=32 set semsys:seminfo_semume=32 These values are considerably larger than the defaults but more in line with the Linux defaults. Please note I have 512MB of memory on my Sparc, so I was not concerned about allocating too much table space. Thanks all for your help, this seems to have solved my problem. DwD > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Wednesday, February 10, 1999 10:01 AM > To: t-ishii@sra.co.jp > Cc: Daryl W. Dunbar; pgsql-hackers@postgreSQL.org > Subject: Re: [HACKERS] PostgreSQL and Solaris 7? > > > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > >>> Increasing # of semaphores should solve the problem, > I guess. I'm > >>> going to try that as soon as I find the way to > increase semaphores. > > Right --- the messages Daryl is seeing indicate he's > running out of > semaphores or semaphore IDs, not file space. (Someone > was too lazy > to create a separate kernel errno for out-of-semaphores.) > > : IpcSemaphoreCreate: semget failed (No space left on device) > ^^^^^^^^^^^^^ > > My guess is that the "WaitOnLock" and "stuck spinlock" > complaints are > artifacts of not being able to recover from the out-of-semaphores > condition. I hope to make this a little more robust in > time for 6.5. > > > 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. > > 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. > > regards, tom lane >
В списке pgsql-hackers по дате отправления: