Hi, Tim,
Tim Allen wrote:
One thing that has been
apparent is that autovacuum has not been able to keep the database
sufficiently tamed. A pg_dump/pg_restore cycle reduced the total
database size from 81G to 36G.
Two first shots:
- Increase your free_space_map settings, until (auto)vacuum
Hi, Tim,
Seems I sent my message to fast, cut in middle of a sencence:
Markus Schaber wrote:
A pg_dump/pg_restore cycle reduced the total
database size from 81G to 36G.
If you still have the original database around,
... can you check wether VACUUM FULL and REINDEX achieve the same effect?
I'd have to agree with you about the specific SAN/setup you're working
with there.I certainly disagree that it's a general property of SAN'sthough.We've got a DS4300 with FC controllers and drives, hosts aregenerally dual-controller load-balanced and it works quite decently.
How are you guys doing
Jeff Trout wrote:
On Jun 16, 2006, at 5:11 AM, Tim Allen wrote:
One curious thing is that some postgres backends seem to spend an
inordinate amount of time in uninterruptible iowait state. I found a
posting to this list from December 2004 from someone who reported
that very same thing. For
Scott Marlowe wrote:
On Thu, 2006-06-15 at 16:50, Tim Allen wrote:
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details
of the EMC SAN
On Mon, Jun 19, 2006 at 08:09:47PM +1000, Tim Allen wrote:
Certainly, the read performance of the SATA disk still beats the SAN,
and there is no way to lie about read performance.
Sure there is: you have the data cached in system RAM. I find it real
hard to believe that you can sustain
John Vincent wrote:
snipped
Is that expected performance, anyone? It doesn't sound right to me. Does
anyone have any clues about what might be going on? Buggy kernel
drivers? Buggy kernel, come to think of it? Does a SAN just not provide
adequate performance for a large
* Tim Allen ([EMAIL PROTECTED]) wrote:
The conclusion I'm drawing here is that this SAN does not perform at all
well, and is not a good database platform. It's sounding from replies
from other people that this might be a general property of SAN's, or at
least the ones that are not
On 6/19/06, Tim Allen [EMAIL PROTECTED] wrote:
As I noted in another thread, the HBA is an Emulex LP1050, and they havea rather old driver for it. I've recommended that they update ASAP. Thishasn't happened yet.Yeah, I saw that in a later thread. I would suggest also that the BIOS settings on the
I'd have to agree with you about the specific SAN/setup you're working
with there.I certainly disagree that it's a general property of SAN'sthough.We've got a DS4300 with FC controllers and drives, hosts aregenerally dual-controller load-balanced and it works quite decently.
How are you guys
* John Vincent ([EMAIL PROTECTED]) wrote:
I'd have to agree with you about the specific SAN/setup you're working
with there. I certainly disagree that it's a general property of SAN's
though. We've got a DS4300 with FC controllers and drives, hosts are
generally dual-controller
Michael Stone wrote:
On Mon, Jun 19, 2006 at 08:09:47PM +1000, Tim Allen wrote:
Certainly, the read performance of the SATA disk still beats the SAN,
and there is no way to lie about read performance.
Sure there is: you have the data cached in system RAM. I find it real
hard to believe that
On Jun 16, 2006, at 6:28 AM, Greg Stark wrote:
I never understood why disk caches on the order of megabytes are
exciting. Why
should disk manufacturers be any better about cache management than OS
authors?
In the case of RAID 5 this could actually work against you since
the RAID
controller
Tim Allen wrote:
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details
of the EMC SAN model, or the type of fibre-channel card at the
Tim Allen wrote:
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details
of the EMC SAN model, or the type of fibre-channel card at the
Alex Turner [EMAIL PROTECTED] writes:
Given the fact that most SATA drives have only an 8MB cache, and your RAID
controller should have at least 64MB, I would argue that the system with the
RAID controller should always be faster. If it's not, you're getting
short-changed somewhere, which
Attached Disks) instead.
/Mikael
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim Allen
Sent: den 15 juni 2006 23:50
To: pgsql-performance@postgresql.org
Subject: [PERFORM] SAN performance mystery
We have a customer who are having performance problems
On 6/16/06, Mikael Carneholm [EMAIL PROTECTED] wrote:
We've seen similar results with our EMC CX200 (fully equipped) when
compared to a single (1) SCSI disk machine. For sequential reads/writes
(import, export, updates on 5-10 30M+ row tables), performance is
downright awful. A big DB update
On Jun 16, 2006, at 5:11 AM, Tim Allen wrote:
One curious thing is that some postgres backends seem to spend an
inordinate amount of time in uninterruptible iowait state. I found
a posting to this list from December 2004 from someone who reported
that very same thing. For example,
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details
of the EMC SAN model, or the type of fibre-channel card at the moment).
They're
On Thu, 2006-06-15 at 16:50, Tim Allen wrote:
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details
of the EMC SAN model, or the type
Tim Allen wrote:
We have a customer who are having performance problems. They have a
large (36G+) postgres 8.1.3 database installed on an 8-way opteron
with 8G RAM, attached to an EMC SAN via fibre-channel (I don't have
details of the EMC SAN model, or the type of fibre-channel card at the
On 6/15/06, Tim Allen [EMAIL PROTECTED] wrote:
snippedIs that expected performance, anyone? It doesn't sound right to me. Doesanyone have any clues about what might be going on? Buggy kerneldrivers? Buggy kernel, come to think of it? Does a SAN just not provide
adequate performance for a large
Brian Hurt [EMAIL PROTECTED] writes:
Tim Allen wrote:
To simplify greatly - single local SATA disk beats EMC SAN by factor
of four.
I'm actually in a not dissimiliar position here- I was seeing the
performance of Postgres going to an EMC Raid over iSCSI running at about
1/2 the speed of
On Thu, 2006-06-15 at 18:24 -0400, Tom Lane wrote:
I agree with Brian's suspicion that the SATA drive isn't properly
fsync'ing to disk, resulting in bogusly high throughput. However,
ISTM a well-configured SAN ought to be able to match even the bogus
throughput, because it should be able to
Given the fact that most SATA drives have only an 8MB cache, and your RAID controller should have at least 64MB, I would argue that the system with the RAID controller should always be faster. If it's not, you're getting short-changed somewhere, which is typical on linux, because the drivers just
26 matches
Mail list logo
