Re: Need to find out which process is hitting hda - Mailing list pgsql-general

From Tom Lane
Subject Re: Need to find out which process is hitting hda
Date
Msg-id 29317.1197618717@sss.pgh.pa.us
Whole thread Raw
In response to Re: Need to find out which process is hitting hda  (Ow Mun Heng <Ow.Mun.Heng@wdc.com>)
List pgsql-general
Ow Mun Heng <Ow.Mun.Heng@wdc.com> writes:
>> vmstat would confirm or disprove that particular guess, since it tracks
>> swap I/O separately.

> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
>  2  6 300132   5684   4324 315888  420   32  1024   644 1309  485 35 11  0 54  0
>  0  6 299820   6768   4328 313004  588   76  3048   576 1263  588 36 12  0 52  0
>  0  6 299428   5424   4340 313700  480   36  2376   104 1291  438 24  9  0 67  0
>  2  6 298836   5108   4268 313788  800    0  2312   216 1428  625 30 10  0 60  0
>  2  6 298316   5692   4192 313044  876    0  1652  1608 1488  656 33 11  0 56  0
>  2  6 298004   6256   4140 312184  560    4  1740  1572 1445  601 42 11  0 47  0

> I kept looking at the io columns and didn't even think of the swap
> partition. It's true that it's moving quite erratically but I won't say
> that it's really thrashing.

Hmmm ... my experience is that the si/so columns should show *zero* under
normal load.  What you're showing here is swap as a sizable percentage
of total I/O load, and with the CPU spending the majority of its time
in I/O wait, that's clearly where you need to focus your attention.

> (YEP, I know I'm RAM starved on this machine)

Yeah, that's what it looks like.  Head down to your local CompUSA and
get some RAM at fire-sale prices ...

            regards, tom lane

pgsql-general by date:

Previous
From: Ow Mun Heng
Date:
Subject: Re: Need to find out which process is hitting hda
Next
From: "Harald Armin Massa"
Date:
Subject: Re: HouseKeeping and vacuum Questions