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

Re: Scalability in postgres

From: Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>
To: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Scalability in postgres
Date: 2009-05-29 00:35:12
Message-ID: 32681901.41243557308404.JavaMail.flavio@presente (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
----- "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> escreveu: 
> On Thu, May 28, 2009 at 12:50 PM, Fabrix <fabrixio1(at)gmail(dot)com> wrote: 
> > 
> > HI. 
> > 
> > Someone had some experience of bad performance with postgres in some server 
> > with many processors? 

I had. 

> > but I have experienced problems with another server that has 8 CPUS quad 
> > core (32 cores). The second one only gives me about 1.5 of performance of 
> > the first one. 

I have had problems with 4 CPUS dual core Hyper Threading (16 logical CPUS). 

> What model CPUs and chipset on the mobo I wonder? 
> > Monitoring (nmon, htop, vmstat) see that everything is fine (memory, HD, 
> > eth, etc) except that processors regularly climb to 100%. 
> > 
> > I can see that the processes are waiting for CPU time: 

> > Have postgres problems of lock or degradation of performance with many 
> > CPU's? 
> > Any comments? 
> Looks like a context switch storm, which was pretty common on older 
> Xeon CPUs. I imagine with enough pg processes running on enough CPUs 
> it could still be a problem. 

I would ask for your kernel version. uname -a please? 

It was possible to make the context work better with 2.4.24 with kswapd patched around here. 1600 connections working fine at this moment. 
Try to lower your memory requirements too. Linux kernel needs some space to page and scale up. Install some more memory otherwise. 


In response to


pgsql-performance by date

Next:From: FabrixDate: 2009-05-29 01:04:32
Subject: Re: Scalability in postgres
Previous:From: Flavio Henrique Araque GurgelDate: 2009-05-29 00:26:32
Subject: Re: Continuent (was: Postgres Clustering)

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