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: 46153D5B.5020001@serioustechnology.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Browse pgsql-admin by date

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