Skip site navigation (1) Skip section navigation (2)

Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...

From: Mark Wong <markw(at)osdl(dot)org>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: Kevin Brown <kevin(at)sysexperts(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...
Date: 2004-10-15 20:39:47
Message-ID: 20041015133947.A9225@osdl.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Oct 15, 2004 at 01:09:01PM -0700, Sean Chittenden wrote:
[snip]
> >
> > This ultimately depends on two things: how much time is spent copying
> > buffers around in kernel memory, and how much advantage can be gained
> > by freeing up the memory used by the backends to store the
> > backend-local copies of the disk pages they use (and thus making that
> > memory available to the kernel to use for additional disk buffering).
> 
> Someone on IRC pointed me to some OSDL benchmarks, which broke down 
> where time is being spent.  Want to know what the most expensive part 
> of PostgreSQL is?  *drum roll*
> 
> http://khack.osdl.org/stp/297960/profile/DBT_2_Profile-tick.sort
> 
> 3967393 total                                      1.7735
> 2331284 default_idle                             36426.3125
> 825716 do_sigaction                             1290.1813
> 133126 __copy_from_user_ll                      1040.0469
>   97780 __copy_to_user_ll                        763.9062
>   43135 finish_task_switch                       269.5938
>   30973 do_anonymous_page                         62.4456
>   24175 scsi_request_fn                           22.2197
>   23355 __do_softirq                             121.6406
>   17039 __wake_up                                133.1172
>   16527 __make_request                            10.8730
>    9823 try_to_wake_up                            13.6431
>    9525 generic_unplug_device                     66.1458
>    8799 find_get_page                             78.5625
>    7878 scsi_end_request                          30.7734
> 
> Copying data to/from userspace and signal handling!!!!  Let's hear it 
> for the need for mmap(2)!!!  *crowd goes wild*
> 
[snip]

I know where the do_sigaction is coming from in this particular case.
Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
Commenting out those two calls out virtually eliminates do_sigaction from
the kernel profile for this workload.  I've lost track of the discussion
over the past year, but I heard a rumor that it was finally addressed to
some degree.  I did understand it touched on a lot of other things, but
can anyone summarize where that discussion has gone?

Mark

In response to

Responses

pgsql-performance by date

Next:From: Doug YDate: 2004-10-15 21:18:12
Subject: Re: Tuning shared_buffers with ipcs ?
Previous:From: Josh BerkusDate: 2004-10-15 20:38:17
Subject: Re: [Testperf-general] Re: First set of OSDL Shared Memscalability results, some wierdness ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group