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 . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
