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 effe
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)vacuu
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 do
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
* 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-controlle
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
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
* 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 strato
John Vincent wrote:
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 database?
Ti
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 161MB/
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
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
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 c
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, bringin
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 to
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 took 5-6h in pre-prod (single SCSI),
and 10-14?h (don't reca
"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,
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 mome
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
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
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 t
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
On 6/15/06, Tim Allen <[EMAIL PROTECTED]> wrote:
Is 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 database?
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
mo
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 ty
25 matches
Mail list logo
