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 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 series
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'ing a big file don't have
this behavior
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
(your mem/2GB).
If I
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: 26308
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 304.085269
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 4GB ram):
[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
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,
-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 Tom,
On Sun, 2005-11-06 at 15
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 objectid from
-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 just uses libpq's pqexec function. The speed
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
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
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
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
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
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?
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 (see
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
all
20 matches
Mail list logo
