On Tue, 13 Jun 2006, Jim Nasby wrote:
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.
What version of FreeBSD are you dealing with here? I'm guessing at least
6.x, but just figured I'd clarify ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend