Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
От | Manfred Spraul |
---|---|
Тема | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 |
Дата | |
Msg-id | 3FA4E51B.5010209@colorfullife.com обсуждение исходный текст |
Ответ на | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 (Mark Wong <markw@osdl.org>) |
Список | 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
В списке pgsql-hackers по дате отправления: