Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

Manfred Spraul <manfred@colorfullife.com>

From: Manfred Spraul <manfred@colorfullife.com>
To: Mark Wong <markw@osdl.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, osdldbt-general@lists.sourceforge.net
Date: 2003-11-02T11:06:03Z
Lists: pgsql-hackers
Mark Wong wrote:

>On Sat, Nov 01, 2003 at 10:29:34PM +0100, Manfred Spraul wrote:
>  
>
>>Mark Wong wrote:
>>
>>    
>>
>>>Yeah, my dbt2 applications are multithreaded.
>>> 
>>>
>>>      
>>>
>>Do you need SIGPIPE delivery in your app? If no, could you try what 
>>happens if you apply the attached patch to postgres, and perform the
>>    signal(SIGPIPE, SIG_IGN);
>>once in your dbt2 app?
>>    
>>
>
>Wow, that patch made a pretty big difference:
>	http://developer.osdl.org/markw/dbt2-pgsql/191/
>	- metric 1605.51
>
>So no one has to look for older mail before I applied that patch:
>	http://developer.osdl.org/markw/dbt2-pgsql/190/
>	- metric 1427.24
>
>Looks like about a 12% improvement in the overall metric.  The first thing I
>noticed is that do_sigaction in the kernel profile almost disappeared.
>
Cool.

>  The
>top few functions in the database profile doesn't appear to have changed much.
>  
>
I've looked at the profile:
The only unusal line is the memcpy(cur_skey, cache->cc_skey, 
sizeof(cur_skey)): it copies 144 byte and needs ~5.3% global cpu time, 
from the 12.1% in SearchCatCache. The cachelines (line size 128 bytes) 
of cc_skey are shared with cc_bucket. 1.8% cpu time is spent in 
DLMoveToFront, the function that moves cache entries around.

Perhaps a scalability problem of the hash table? The implementation 
moves the entries around all the time, i.e. the worst case for cache 
line transfers.

--
    Manfred