From: | Tory M Blue <tmblue(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance question 83 GB Table 150 million rows, distinct select |
Date: | 2011-11-17 02:42:55 |
Message-ID: | CAEaSS0Y2W=2h6aGj0eUnnjP7JnVUqtjj+7_mczQVBfGQ3L8ZGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Nov 16, 2011 at 6:27 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 17 Listopad 2011, 2:57, Scott Marlowe wrote:
>> On Wed, Nov 16, 2011 at 4:59 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>>
>>> But you're right - you're not bound by I/O (although I don't know what
>>> are
>>> those 15% - iowait, util or what?). The COUNT(DISTINCT) has to actually
>>> keep all the distinct values to determine which are actually distinct.
>>
>> Actually I meant to comment on this, he is IO bound. Look at % Util,
>> it's at 99 or 100.
>>
>> Also, if you have 16 cores and look at something like vmstat you'll
>> see 6% wait state. That 6% represents one CPU core waiting for IO,
>> the other cores will add up the rest to 100%.
>
> Aaaah, I keep forgetting about this and I somehow ignored the iostat
> results too. Yes, he's obviously IO bound.
I'm not so sure on the io-bound. Been battling/reading about it all
day. 1 CPU is pegged at 100%, but the disk is not. If I do something
else via another CPU I have no issues accessing the disks,
writing/deleting/reading. It appears that what was said about this
being very CPU intensive makes more sense to me. The query is only
using 1 CPU and that appears to be getting overwhelmed.
%util: This number depicts the percentage of time that the device
spent in servicing requests.
On a large query, or something that is taking a while it's going to be
writing to disk all the time and I'm thinking that is what the util is
telling me, especially since IOwait is in the 10-15% range.
Again just trying to absorb
avg-cpu: %user %nice %system %iowait %steal %idle
0.93 0.00 0.60 9.84 0.00 88.62
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 86.50 3453.00 1.50 55352.00 16.00
16.03 5.24 0.66 0.29 100.00
I mean await time and service time are in the .29 to .66 msec that
doesn't read as IObound to me. But I'm more than willing to learn
something not totally postgres specific.
But I just don't see it... Average queue size of 2.21 to 6, that's
really not a ton of stuff "waiting"
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 3060.00 2.00 49224.00 20.00
16.08 2.21 0.76 0.33 99.95
avg-cpu: %user %nice %system %iowait %steal %idle
0.80 0.00 0.51 11.01 0.00 87.68
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 5.00 3012.50 3.00 48200.00 92.00
16.01 2.11 0.74 0.33 99.95
avg-cpu: %user %nice %system %iowait %steal %idle
0.93 0.00 0.60 9.84 0.00 88.62
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 86.50 3453.00 1.50 55352.00 16.00
16.03 5.24 0.66 0.29 100.00
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2011-11-17 03:02:56 | Re: Performance question 83 GB Table 150 million rows, distinct select |
Previous Message | Tomas Vondra | 2011-11-17 02:27:35 | Re: Performance question 83 GB Table 150 million rows, distinct select |