Re: Sudden drop in DBb performance

On 5 Září 2011, 21:07, Andy Colson wrote:
> On 09/05/2011 01:45 PM, Scott Marlowe wrote:
>> On Mon, Sep 5, 2011 at 8:08 AM, Gerhard Wohlgenannt<wohlg(at)ai(dot)wu(dot)ac(dot)at>
>> wrote:
>>> Below please find the results of vmstat 2 over some periode of time ..
>>> with
>>> normal database / system load.
>>>
> 2 1 1344204 240924 104156 31462484 350 0 1906 234 3687 4512 12 3
> 77 9
>>
>> Your IO Wait is actually pretty high. On an 8 core machine, 12.5%
>> means one core is doing nothing but waiting for IO.
>>
>
> My server is 2-core, so these numbers looked fine by me. I need to
> remember core count when I look at these.
>
> So the line above, for 2 core's would not worry me a bit, but on 8 cores,
> it pretty much means one core was pegged (with 9% wait? Or is it one core
> was pegged, and another was 72% io wait?)

AFAIK it's as if one core was 72% io wait. Anyway that's exactly why I was
asking for "iostat -x" because the util% gives a better idea of what's
going on.

> I have always loved the vmstat output, but its starting to get confusing
> when you have to take core's into account. (And my math was never strong
> in the first place :-) )

That's why I love dstat, just do this

$ dstat -C 0,1,2,3,4,5,6,7

and you know all you need.

> Good catch, thanks Scott.

Yes, good catch.

Still, this does not explain why the queries were running fast before, and
why the RAID array is so sluggish. Not to mention that we don't know what
were the conditions when collecting those numbers (were the VMs off or
running?).

Tomas