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