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

Re: User concurrency thresholding: where do I look?

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>,"Josh Berkus" <josh(at)agliodbs(dot)com>,<pgsql-performance(at)postgresql(dot)org>,"Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Subject: Re: User concurrency thresholding: where do I look?
Date: 2007-07-23 08:51:08
Message-ID: 1185180668.4284.149.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 2007-07-20 at 16:57 -0400, Tom Lane wrote:
> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:
> > What its saying is that there are holds/waits in trying to get locks 
> > which are locked at Solaris user library levels called from the  
> > postgresql functions:
> > For example both the following functions are hitting on the same mutex 
> > lock  0x10059e280  in Solaris Library call:
> > postgres`AllocSetDelete+0x98
> > postgres`AllocSetAlloc+0x1c4
> 
> That's a perfect example of the sort of useless overhead that I was
> complaining of just now in pgsql-patches.  Having malloc/free use
> an internal mutex is necessary in multi-threaded programs, but the
> backend isn't multi-threaded.  And yet, apparently you can't turn
> that off in Solaris.
> 
> (Fortunately, the palloc layer is probably insulating us from malloc's
> performance enough that this isn't a huge deal.  But it's annoying.)

There is one thing that the palloc layer doesn't handle: EState. All
other memory contexts have a very well chosen initial allocation that
prevents mallocs during low-medium complexity OLTP workloads.

EState is about 8300 bytes, so just above the large allocation limit.
This means that every time we request an EState, i.e. at least once per
statement we need to malloc() and then later free().

Would it be worth a special case in the palloc system to avoid having to
repeatedly issue external memory allocation calls?

-- 
  Simon Riggs
  EnterpriseDB  http://www.enterprisedb.com


In response to

Responses

pgsql-performance by date

Next:From: Michael StoneDate: 2007-07-23 11:51:50
Subject: Re: insert vs select into performance
Previous:From: Adam Tauno WilliamsDate: 2007-07-22 18:32:45
Subject: Re: Simple select hangs while CPU close to 100%

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