Date: Thu, 24 May 2012 22:29:55 +0530 (IST)
From: "Rajesh Kumar. Mallah" <mallah@tradeindia.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-performance@postgresql.org
Message-ID: 
 <8120287.465321337878795023.JavaMail.root@zmbox01.trade-india-local.com>
In-Reply-To: <20120524155737.GP1267@tamriel.snowman.net>
Subject: Re: High load average in 64-core server ,
  no I/O wait and CPU is idle
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

----- "Stephen Frost" <sfrost@snowman.net> wrote:

| From: "Stephen Frost" <sfrost@snowman.net>
| To: "Rajesh Kumar. Mallah" <mallah@tradeindia.com>
| Cc: pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:27:37 PM
| Subject: Re: [PERFORM] High load average in 64-core server ,  no I/O wait and CPU is idle
|
| Rajesh,
| 
| * Rajesh Kumar. Mallah (mallah@tradeindia.com) wrote:
| > We are  puzzled why the CPU and DISK I/O system are not being
| utilized 
| > fully and would seek lists' wisdom on that.
| 
| What OS is this?  What kernel version?

Dear Frost ,

We are running linux with kernel 3.2.X 
(which has the lseek improvements)

| 
| > just a thought, will it be a good idea to partition the host
| hardware 
| > to 4 equal  virtual environments , ie 1 for master (r/w) and 3
| slaves r/o
| > and distribute the r/o load on the 3 slaves ?
| 
| Actually, it might help with 9.1, if you're really running into some
| scalability issues in our locking area..  You might review this:
| 
| http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html
| 
| That's a pretty contrived test case, but I suppose it's possible your
| case is actually close enough to be getting affected also..

Thanks for the reference , even i thought so (LockManager) ,
but we are actually also running out db max connections (also) 
( which is currently at 600) , when that happens  something at 
the beginning of the application stack also gets dysfunctional and it 
changes the very input to the system. ( think of negative feedback systems ) 

It is sort of complicated but i will definitely update list , 
when i get to  the point of putting the blame on DB  :-) .

Regds
Mallah.

| 
| 	Thanks,
| 
| 		Stephen