On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
FYI, the biggest source of contention is via semop() - it might be
possible to optimize that some more in FreeBSD, I don't know.
Yeah, I've seen PostgreSQL on FreeBSD fall over at high load with
a lot
of procs in either semwait or semlock. :(
Part of that is Giant contention again; for example on 6.x semop() and
setproctitle() both want to acquire it, so they'll fight with each
other and with anything else on the system that wants Giant
(e.g. IPv6, or the USB stack, etc). As I mentioned Giant is not an
issue here going forward, but there is still as much lock contention
just between semop() calls running on different CPUs. It may be
possible for someone to implement more fine-grained locking here, but
I don't know if there is available interest.
BTW, there's another FBSD performance odditiy I've run across. Running
pg_dump -t email_contrib -COx stats | bzip2 > ec.sql.bz2 &
which dumps the email_contrib table to bzip2 then to disk, the OS
won't use more than 1 CPU on an SMP system... unless the data is
cached. According to both gstat and systat -v, the system isn't I/O
bound; both are reporting the RAID10 with that table on it as only
about 10% busy. If I let that command run for a bit then cancel it
and re-start it so that the beginning of that table is in cache, it
will use one entire CPU for bzip2, which is what I'd expect to happen.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
