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 jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
