Re: can't handle large number of INSERT/UPDATEs - Mailing list pgsql-performance

From Curtis Zinzilieta
Subject Re: can't handle large number of INSERT/UPDATEs
Date
Msg-id Pine.LNX.4.44.0410261557560.23730-100000@hyperion2.norchemlab.com
Whole thread Raw
In response to Re: can't handle large number of INSERT/UPDATEs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: can't handle large number of INSERT/UPDATEs
List pgsql-performance
On Tue, 26 Oct 2004, Tom Lane wrote:

> "Anjan Dave" <adave@vantage.com> writes:
> > One thing I am not sure is why 'bi' (disk writes) stays at 0 mostly,
> > it's the 'bo' column that shows high numbers (reads from disk). With so
> > many INSERT/UPDATEs, I would expect it the other way around...
>
> Er ... it *is* the other way around.  bi is blocks in (to the CPU),
> bo is blocks out (from the CPU).
>
>             regards, tom lane

Ummm.....

[curtisz@labsoft T2]$ man vmstat
<snip>
FIELD DESCRIPTIONS
<snip>
   IO
       bi: Blocks sent to a block device (blocks/s).
       bo: Blocks received from a block device (blocks/s).

And on my read-heavy 7.4.2 system (running on rh8 at the moment....)
(truncated for readability...)

[root@labsoft T2]# vmstat 1
   procs                      memory    swap          io     system
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us
 0  0  0 127592  56832 365496 2013788   0   1     3     6    4     0   4
 2  0  0 127592  56868 365496 2013788   0   0     0     0  363   611   1
 1  0  0 127592  57444 365508 2013788   0   0     8   972 1556  3616  11
 0  0  1 127592  57408 365512 2013800   0   0     0   448  614  1216   5
 0  0  0 127592  56660 365512 2013800   0   0     0     0  666  1150   6
 0  3  1 127592  56680 365512 2013816   0   0    16   180 1280  2050   2
 0  0  0 127592  56864 365516 2013852   0   0    20   728 2111  4360  11
 0  0  0 127592  57952 365544 2013824   0   0     0   552 1153  2002  10
 0  0  0 127592  57276 365544 2013824   0   0     0   504  718  1111   5
 1  0  0 127592  57244 365544 2013824   0   0     0   436 1495  2366   7
 0  0  0 127592  57252 365544 2013824   0   0     0     0  618  1380   5
 0  0  0 127592  57276 365556 2014192   0   0   360  1240 2418  5056  14
 2  0  0 127592  56664 365564 2014176   0   0     0   156  658  1349   5
 1  0  0 127592  55864 365568 2014184   0   0     0  1572 1388  3598   9
 2  0  0 127592  56160 365572 2014184   0   0     0   536 4860  6621  13

Which seems appropriate for both the database and the man page....

-Curtis



pgsql-performance by date:

Previous
From: "Anjan Dave"
Date:
Subject: Re: can't handle large number of INSERT/UPDATEs
Next
From: Thomas F.O'Connell
Date:
Subject: Re: [PATCHES] [HACKERS] ARC Memory Usage analysis