On Tue, Jun 13, 2006 at 03:55:38PM -0500, 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.
Hmm, odd..maybe something with the scheduler. I'd need access to a test case to be able to figure it out though. Kris
pgpG0gnuPegHa.pgp
Description: PGP signature
