Re: postgresql and process titles

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