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

problems after migration to new hardware

From: Geoffrey <lists(at)serioustechnology(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: problems after migration to new hardware
Date: 2007-04-05 18:18:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
We moved our application to a new machine last night. It is a Dell 
PowerEdge 6950 2X Dual Core. AMD Opteron 8214 2.2Ghz. 8GB Memory. The 
machine is running Redhat AS 4 Upd 4 and Redhat Cluster Suite. The SAN 
is an EMC SAS connected via fibre. We are using Postgres 7.4.16. We have 
recently had some major hardware issues and replaced the hardware with 
brand new Dell equipment. We expected a major performance increase over 
the previous being the old equipment was nearly three years old

I will try and explain how things are configured. We have 10 separate 
postmasters running 5 on each node. Each of the postmasters is a single 
instance of each database. Each database is separated by division and 
also we have them separate so we can restart an postmaster with needing 
to restart all databases My largest database is about 7 GB. And the 
others run anywhere from 100MB - 1.8GB.

The other configuration was RHEL3 and Postgres 7.4.13 and Redhat Cluster 
Suite. The application seemed to run much faster on the older equipment.

My thoughts on the issues are that I could be something with the OS
tuning. Here is what my kernel.shmmax, kernel.shmall = 1073741824. Is 
there something else that I could tune in the OS. My max_connections=35 
and shared buffers=8192 for my largest database.

Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

pgsql-admin by date

Next:From: Bhella, ParamjeetDate: 2007-04-05 21:13:45
Subject: Restoring single database from an export dump of a cluster
Previous:From: Gabriele BartoliniDate: 2007-04-05 11:59:54
Subject: Advice on migration without down-time

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