Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
Mark Cave-Ayland wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 31 January 2005 16:35 To: Mark Cave-Ayland Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores? (cut) Judging by the symptoms, you have built a version with what we now call --disable-spinlocks; that is, it didn't figure out how to do assembly TAS on your platform and fell back to using SysV semaphores for spinlocks. Quite aside from the drain on semaphores, the performance is going to be spectacularly bad, so you'd better fix that. regards, tom lane Hi Tom, I'd just about managed to come to the same conclusion before your email arrived by spending the afternoon with gdb tracing into the LWLock code :) I've just installed 7.4.6 on the same box and this time the spinlocks are correctly picked up and everything works as expected. I think rather than fixing the 7.3.x source, we'll take the plunge and plan for a complete dump and restore of the database cluster over a weekend. And with 7.4 and later we will throw a configure error if we don't find native spinlocks so you will have no surprises in the future. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 31 January 2005 16:35 To: Mark Cave-Ayland Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores? (cut) Judging by the symptoms, you have built a version with what we now call --disable-spinlocks; that is, it didn't figure out how to do assembly TAS on your platform and fell back to using SysV semaphores for spinlocks. Quite aside from the drain on semaphores, the performance is going to be spectacularly bad, so you'd better fix that. regards, tom lane Hi Tom, I'd just about managed to come to the same conclusion before your email arrived by spending the afternoon with gdb tracing into the LWLock code :) I've just installed 7.4.6 on the same box and this time the spinlocks are correctly picked up and everything works as expected. I think rather than fixing the 7.3.x source, we'll take the plunge and plan for a complete dump and restore of the database cluster over a weekend. Many thanks, Mark. WebBased Ltd South West Technology Centre Tamar Science Park Plymouth PL6 8BT T: +44 (0)1752 791021 F: +44 (0)1752 791023 W: http://www.webbased.co.uk ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] 7.3.8 under FC3 takes excessive semaphores?
Hi everyone, I'm trying to install a copy of PostgreSQL 7.3.8 on FC3 x86_64, and having a very strange problem with shared memory in that PostgreSQL seems to be taking far too many semaphores for the parameters in the postgresql.conf file. I've raised this with some of the members of the IRC channel, and they have been unable to explain why this is happening. Using the default parameters from a fresh initdb, if I increase shared buffers much above 1000 then the postmaster refuses to start with the following error: - IpcSemaphoreCreate: semget(key=5433025, num=17, 03600) failed: No space left on device This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 32). The PostgreSQL Administrator's Guide contains more information about configuring your system for PostgreSQL. - Even when I have increased the values of SEMMNI and SEMMNS far above their default values, the postmaster still refuses to start. When I drop shared_buffers back to 1000, the postmaster starts but takes 127(??!) different semaphores arrays each with 17 elements (as listed using ipcs). To check this, I installed the same source on a FC1 i386 machine to do a comparison, using my original shared_buffers value of 1, and found that a successfully running postmaster only takes 3 semaphore arrays with 17 elements. Digging into the source, I added an elog() at line 227 in src/backend/port/sysv_sema.c and found that on the FC1 i386 machine, the loop in IpcSemaphoreCreate() is called only 3 times. Doing the same on the FC3 x86_64 machine, the loop seems to cycle endlessly until I run out of semaphores. Can anyone suggest a reason why the behaviour is so different between FC3 x86_64 and FC1 i386? I'm thinking it may be either to do with the x86_64 platform or perhaps the newer version of gcc used to compile from source. Any pointers in the right direction would be gratefully received :) Kind regards, Mark. WebBased Ltd South West Technology Centre Tamar Science Park Plymouth PL6 8BT T: +44 (0)1752 791021 F: +44 (0)1752 791023 W: http://www.webbased.co.uk ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
Mark Cave-Ayland [EMAIL PROTECTED] writes: I'm trying to install a copy of PostgreSQL 7.3.8 on FC3 x86_64, and having a very strange problem with shared memory in that PostgreSQL seems to be taking far too many semaphores for the parameters in the postgresql.conf file. Judging by the symptoms, you have built a version with what we now call --disable-spinlocks; that is, it didn't figure out how to do assembly TAS on your platform and fell back to using SysV semaphores for spinlocks. Quite aside from the drain on semaphores, the performance is going to be spectacularly bad, so you'd better fix that. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
