Re: can't handle large number of INSERT/UPDATEs

From: Curtis Zinzilieta <curtisz(at)norchemlab(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Anjan Dave <adave(at)vantage(dot)com>, Matt Clark <matt(at)ymogen(dot)net>, Rod Taylor <pg(at)rbt(dot)ca>, Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: can't handle large number of INSERT/UPDATEs
Date: 2004-10-26 23:04:35
Message-ID: Pine.LNX.4.44.0410261557560.23730-100000@hyperion2.norchemlab.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On Tue, 26 Oct 2004, Tom Lane wrote:

> "Anjan Dave" <adave(at)vantage(dot)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(at)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(at)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas F.O'Connell 2004-10-27 00:09:22 Re: [PATCHES] [HACKERS] ARC Memory Usage analysis
Previous Message Anjan Dave 2004-10-26 22:45:37 Re: can't handle large number of INSERT/UPDATEs