Hi Luke,
> It is very important with the 3Ware cards to match the driver to the
> firmware revision.
> So, if you can get your “dd bigfile” test to write data at 50MB/s+
> with a blocksize of 8KB, you should be doing well enough.
I recompiled my kernel, added the driver and:
[EMAIL PROTECTED]:~
Hi Luke,
On Tue, 2005-11-15 at 22:07 -0800, Luke Lonergan wrote:
> You might update your driver,
I will do that (but I admit that I am not looking forward to it. When I
was young and did not make money with my computer, I liked challenges
like compiling kernels and not being able to boot the com
Title: Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware
Joost,
On 11/15/05 11:51 AM, "Joost Kraaijeveld" <[EMAIL PROTECTED]> wrote:
On Tue, 2005-11-15 at 12:41 -0700, Steve Wampler wrote:
> Joost Kraaijeveld wrote:
> > If I understand correctly (I have
On Tue, 2005-11-15 at 12:41 -0700, Steve Wampler wrote:
> Joost Kraaijeveld wrote:
> > If I understand correctly (I have 4GB ram):
> >
> > [EMAIL PROTECTED]:~/tmp$ dd if=/dev/zero of=bigfile bs=8k count=100
> > 100+0 records in
> > 100+0 records out
> > 819200 bytes transferred in
Joost Kraaijeveld wrote:
> If I understand correctly (I have 4GB ram):
>
> [EMAIL PROTECTED]:~/tmp$ dd if=/dev/zero of=bigfile bs=8k count=100
> 100+0 records in
> 100+0 records out
> 819200 bytes transferred in 304.085269 seconds (26939812 bytes/sec)
>
> Which looks suspicious: 2
Hi Luke,
On Tue, 2005-11-15 at 10:42 -0800, Luke Lonergan wrote:
> With RAID5, it could matter a lot what block size you run your “dd
> bigfile” test with. You should run “dd if=/dev/zero of=bigfile bs=8k
> count=50” for a 2GB main memory machine, multiply the count by
> (/2GB).
If I understa
Title: Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware
Joost,
On 11/15/05 8:35 AM, "Joost Kraaijeveld" <[EMAIL PROTECTED]> wrote:
thousand go relatively fast, after that PostgreSQL crawls to a halt
(other "benchmarks" like bonnie++ or just dd'
Hi Dave,
On Mon, 2005-11-14 at 18:51 -0500, Dave Cramer wrote:
> Joost,
>
> I've got experience with these controllers and which version do you
> have. I'd expect to see higher than 50MB/s although I've never tried
> RAID 5
>
> I routinely see closer to 100MB/s with RAID 1+0 on their 9000 se
Joost,
I've got experience with these controllers and which version do you
have. I'd expect to see higher than 50MB/s although I've never tried
RAID 5
I routinely see closer to 100MB/s with RAID 1+0 on their 9000 series
I would also suggest that shared buffers should be higher than 7500,
Dave Page wrote:
Now *I* am confused. What does PgAdmin do more than giving
the query to
the database?
Nothing - it just uses libpq's pqexec function. The speed issue in
pgAdmin is rendering the results in the grid which can be slow on some
OS's due to inefficiencies in some grid controls
Where are the pg_xlog and data directories with respect to each other?
From this IOStat it looks like they might be on the same partition,
which is not ideal, and actualy surprising that throughput is this
good. You need to seperate pg_xlog and data directories to get any
kind of reasonable perfo
> -Original Message-
> From: Joost Kraaijeveld [mailto:[EMAIL PROTECTED]
> Sent: 07 November 2005 09:03
> To: Dave Page
> Cc: Tom Lane; Pgsql-Performance
> Subject: RE: [PERFORM] Performance PG 8.0 on dual opteron /
> 4GB / 3ware
>
> > Nothing - it jus
Hi Dave,
On Mon, 2005-11-07 at 08:51 +, Dave Page wrote:
> > On Sun, 2005-11-06 at 15:26 -0500, Tom Lane wrote:
> > > I'm confused --- where's the 82sec figure coming from, exactly?
> > >From actually executing the query.
> >
> > >From PgAdmin:
> >
> > -- Executing query:
> > select objecti
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Joost Kraaijeveld
> Sent: 07 November 2005 04:26
> To: Tom Lane
> Cc: Pgsql-Performance
> Subject: Re: [PERFORM] Performance PG 8.0 on dual opteron /
> 4GB / 3ware
>
Hi Christopher,
On Mon, 2005-11-07 at 12:37 +0800, Christopher Kings-Lynne wrote:
> > Now *I* am confused. What does PgAdmin do more than giving the query to
> > the database?
>
> It builds it into the data grid GUI object.
But my initial question was about a query that does not produce data at
a
On Mon, 2005-11-07 at 12:37 +0800, Christopher Kings-Lynne wrote:
> > Now *I* am confused. What does PgAdmin do more than giving the query to
> > the database?
>
> It builds it into the data grid GUI object.
Is that not the difference between the total query runtime and the data
retrieval runtime
Now *I* am confused. What does PgAdmin do more than giving the query to
the database?
It builds it into the data grid GUI object.
Chris
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresq
Hi Tom,
On Sun, 2005-11-06 at 15:26 -0500, Tom Lane wrote:
> I'm confused --- where's the 82sec figure coming from, exactly?
>From actually executing the query.
>From PgAdmin:
-- Executing query:
select objectid from prototype.orders
Total query runtime: 78918 ms.
Data retrieval runtime: 188822
Joost Kraaijeveld <[EMAIL PROTECTED]> writes:
> Explain analyse (with PgAdmin):
> ...
> Total runtime: 5049.467 ms
> Actual execution time: 82163 MS (without getting the data)
I'm confused --- where's the 82sec figure coming from, exactly?
We've heard reports of performance issues in PgAdmin with
On Sun, 2005-11-06 at 12:17 -0500, Tom Lane wrote:
> Does that table have any triggers that would fire on the update?
Alas, no trigger, constrainst, foreign keys, indixes (have I forgotten
something?)
All queries are slow. E.g (after vacuum):
select objectid from prototype.orders
Explain analyse
Joost Kraaijeveld <[EMAIL PROTECTED]> writes:
> I am experiencing very long update queries and I want to know if it
> reasonable to expect them to perform better.
Does that table have any triggers that would fire on the update?
regards, tom lane
-
21 matches
Mail list logo