- "Alan McKay" escreveu:
> CentOS / PostgreSQL shop over here.
>
> Our system
> IBM 3650 - quad 2Ghz e5405 Xeon
> 8K SAS RAID Controller
> 6 x 300G 15K/RPM SAS Drives
> /dev/sda - 2 drives configured as a RAID 1 for 300G for the OS
> /dev/sdb - 3 drives configured as RAID5 for 600G for the DB
I would ask for your kernel version. uname -a please?
> sure, and thanks for you answer Flavio...
>
> uname -a
> Linux SERVIDOR-A 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64
> x86_64 x86_64 GNU/Linux
>
> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5
- "Scott Marlowe" escreveu:
> On Thu, May 28, 2009 at 12:50 PM, Fabrix 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
- "Alan McKay" escreveu:
> Hmmm. Anyone out there have the Continuent solution working with PostgreSQL?
> If so, what release? We're at 8.3 right now.
I have tested Sequoia 2.10.10 with a high transaction rate database with good
servers and plenty of memory. Since that's a OLTP system the
- "Scott Marlowe" escreveu:
> Oh my lord, that is a foot gun waiting to go off. Assuming 2k
> connections, and somehow a fair number of them went active with big
> sorts, you'd be able to exhaust all physical memory with about 8 to
> 16 connections. Lower work_mem now. To something like 1
Hello all
In a dedicated server with 16 cores and 16GB of RAM running PostgreSQL 8.2.5 we
have a database with basically two kinds of transactions:
- short transactions with a couple of updates and inserts that runs all the
day;
- batch data loads with hundreds of inserts that runs several t
