Brian,
Any idea what your bottleneck is? You can find out at a crude level by
attaching an strace to the running backend, assuming it¹s running long
enough to grab it, then look at what the system call breakdown is.
Basically, run one of your long insert streams, do a ³top² to find which
process
Brian Hurt <[EMAIL PROTECTED]> writes:
> For long involved reasons I'm hanging out late at work today, and rather
> than doing real, productive work, I thought I'd run some benchmarks
> against our development PostgreSQL database server. My conclusions are
> at the end.
Ummm ... you forgot to
For long involved reasons I'm hanging out late at work today, and rather
than doing real, productive work, I thought I'd run some benchmarks
against our development PostgreSQL database server. My conclusions are
at the end.
The purpose of the benchmarking was to find out how fast Postgres w
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
11 matches
Mail list logo
