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
for DAD (Direct 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 perfo
"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
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 runn
gs, the cache page size is 8KB (can be increased or decreased), and the stripe element size of 128 sectors default.
Thanks,
Anjan
-Original Message-
From: Mr Pink [mailto:[EMAIL PROTECTED]
Sent: Thu 9/23/2004 11:39 AM
To: Anjan Dave; [EMAIL PROTECTED]
Cc:
Subject: Re: [PERFORM]
ailto:[EMAIL PROTECTED]
Sent: Thu 9/23/2004 11:39 AM
To: Anjan Dave; [EMAIL PROTECTED]
Cc:
Subject: Re: [PERFORM] SAN performance
Hi,
I expect you mean RAID 1/0 or 1+0 since the CX300 didn't support RAID 10 last
tim
Hi,
I expect you mean RAID 1/0 or 1+0 since the CX300 didn't support RAID 10 last time I
looked.
Whether you are using a SAN or not, you should consider putting the WAL files (pg_xlog
folder) on
seperate diskes from the DB. Since the log files are mostly written to, not read from
you could
jus
Hello,
I’ll be moving a DB from internal RAID-10 SCSI storage
to an EMC CX300 FC RAID-10 LUN, bound to the host. I’ve setup a test host
machine and a test LUN. The /var/lib/pgsql/data folder is sym-linked to a partition
on the LUN.
Other than the shared_buffers, effective cache siz
30 matches
Mail list logo
