Re: Query Performance and IOWait

From: "Anjan Dave" <adave(at)vantage(dot)com>
To: "Andrew Janian" <ajanian(at)scottrade(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query Performance and IOWait
Date: 2004-11-22 15:20:14
Message-ID: 4BAFBB6B9CC46F41B2AD7D9F4BBAF78501D6D283@vt-pe2550-001.vantage.vantage.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Check the linux-dell list for more...The PERC3/Di cards are specifically
Adaptec, not most. PERC4/DC is LSI Megaraid. Unless you buy the cheaper
version, most will come with battery.

-anjan

-----Original Message-----
From: Andrew Janian [mailto:ajanian(at)scottrade(dot)com]
Sent: Friday, November 19, 2004 4:22 PM
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Query Performance and IOWait

The data that we are accessing is via QLogic cards connected to an EMC
Clarion. We have tried it on local SCSI disks with the same (bad)
results.

When the machine gets stuck in a 100% IOWAIT state it often crashes soon
after that.

The disks are fine, have been replaced and checked.

Here are my results from hdparm -Tt /dev/sda1 (which is the EMC disk
array)
/dev/sda1:
Timing buffer-cache reads: 2976 MB in 2.00 seconds = 1488.00 MB/sec
Timing buffered disk reads: 44 MB in 3.13 seconds = 14.06 MB/sec

-----Original Message-----
From: Dave Cramer [mailto:pg(at)fastcrypt(dot)com]
Sent: Thursday, November 18, 2004 11:14 AM
To: Andrew Janian
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Query Performance and IOWait

Andrew,

Dell's aren't well known for their disk performance, apparently most of
the perc controllers sold with dell's are actually adaptec controllers.
Also apparently they do not come with the battery required to use the
battery backed up write cache ( In fact according to some Dell won't
even sell the battery to you). Also Dell's monitoring software is quite
a memory hog.

Have you looked at top ?, and also hdparm -Tt /dev/sd?

Dave

Andrew Janian wrote:

>Hello All,
>
>I have a setup with a Dell Poweredge 2650 with Red Hat and Postgres
7.4.5 with a database with about 27GB of data. The table in question
has about 35 million rows.
>
>I am running the following query:
>
>SELECT *
>FROM mb_fix_message
>WHERE msg_client_order_id IN (
> SELECT msg_client_order_id
> FROM mb_fix_message
> WHERE msg_log_time >= '2004-06-01'
> AND msg_log_time < '2004-06-01 13:30:00.000'
> AND msg_message_type IN ('D','G')
> AND mb_ord_type = '1'
> )
> AND msg_log_time > '2004-06-01'
> AND msg_log_time < '2004-06-01 23:59:59.999'
> AND msg_message_type = '8'
> AND (mb_raw_text LIKE '%39=1%' OR mb_raw_text LIKE '%39=2%');
>
>with the following plan:
>
>
QUERY PLAN
>Nested Loop IN Join (cost=0.00..34047.29 rows=1 width=526)
> -> Index Scan using mfi_log_time on mb_fix_message
(cost=0.00..22231.31 rows=2539 width=526)
> Index Cond: ((msg_log_time > '2004-06-01 00:00:00'::timestamp
without time zone) AND (msg_log_time < '2004-06-01
23:59:59.999'::timestamp without time zone))
> Filter: (((msg_message_type)::text = '8'::text) AND
(((mb_raw_text)::text ~~ '%39=1%'::text) OR ((mb_raw_text)::text ~~
'%39=2%'::text)))
> -> Index Scan using mfi_client_ordid on mb_fix_message
(cost=0.00..445.56 rows=1 width=18)
> Index Cond: (("outer".msg_client_order_id)::text =
(mb_fix_message.msg_client_order_id)::text)
> Filter: ((msg_log_time >= '2004-06-01 00:00:00'::timestamp
without time zone) AND (msg_log_time < '2004-06-01 13:30:00'::timestamp
without time zone) AND ((msg_message_type)::text = 'D'::text) OR
((msg_message_type)::text = 'G'::text)) AND ((mb_ord_type)::text =
'1'::text))
>
>While running, this query produces 100% iowait usage on its processor
and takes a ungodly amount of time (about an hour).
>
>The postgres settings are as follows:
>
>shared_buffers = 32768 # min 16, at least max_connections*2,
8KB each
>sort_mem = 262144 # min 64, size in KB
>
>And the /etc/sysctl.conf has:
>kernel.shmall = 274235392
>kernel.shmmax = 274235392
>
>The system has 4GB of RAM.
>
>I am pretty sure of these settings, but only from my reading of the
docs and others' recommendations online.
>
>Thanks,
>
>Andrew Janian
>OMS Development
>Scottrade Financial Services
>(314) 965-1555 x 1513
>Cell: (314) 369-2083
>
>---------------------------(end of
broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Browse pgsql-performance by date

  From Date Subject
Next Message sarlav kumar 2004-11-22 19:41:25 Re: help needed -- sequential scan problem
Previous Message Markus Schaber 2004-11-22 15:01:15 Re: Index usage for sorted query