Turns out the man page of vmstat in procps was changed on Oct 8 2002:
http://cvs.sourceforge.net/viewcvs.py/procps/procps/vmstat.8?r1=1.1&r2=1.2
in reaction to a debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=157935
--
Markus Bertheau <[EMAIL PROTECTED]>
and certainly anyone who's been around a computer more than a week or
two knows which direction "in" and "out" are customarily seen from.
regards, tom lane
Apparently not whoever wrote the man page that everyone copied ;-)
Interesting. I checked this on several machines. They actually
or" <[EMAIL PROTECTED]>; "Postgresql Performance"
(B<[EMAIL PROTECTED]>
(BSent: Wednesday, October 27, 2004 12:21 PM
(BSubject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
(B
(B
(B> Curtis Zinzilieta <[EMAIL PROTECTED]> writes:
(B>>
Tom Lane wrote:
Curtis Zinzilieta <[EMAIL PROTECTED]> writes:
On Tue, 26 Oct 2004, Tom Lane wrote:
Er ... it *is* the other way around. bi is blocks in (to the CPU),
bo is blocks out (from the CPU).
Ummm.
[EMAIL PROTECTED] T2]$ man vmstat
bi: Blocks sent to a block device (blocks/s).
Curtis Zinzilieta <[EMAIL PROTECTED]> writes:
> On Tue, 26 Oct 2004, Tom Lane wrote:
>> Er ... it *is* the other way around. bi is blocks in (to the CPU),
>> bo is blocks out (from the CPU).
> Ummm.
> [EMAIL PROTECTED] T2]$ man vmstat
>bi: Blocks sent to a block device (blocks/s).
>
27;ll read about it if there's some info on it
somewhere.
Thanks,
Anjan
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Tue 10/26/2004 8:42 PM
To: [EMAIL PROTECTED]
Cc: Anjan Dave; Tom Lane; Rod Taylor
Subject: Re: [PERFORM] can't handle large numb
Anjan,
> Oct 26 17:26:25 vl-pe6650-003 postgres[14273]: [4-1] LOG: recycled
> transaction
> log file "000B0082"
> ...
> Oct 26 17:31:27 vl-pe6650-003 postgres[14508]: [2-1] LOG: recycled
> transaction
> log file "000B0083"
> Oct 26 17:31:27 vl-pe6650-003 postgres[14508]: [3-1] LO
On Tue, 26 Oct 2004, Tom Lane wrote:
> "Anjan Dave" <[EMAIL PROTECTED]> 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...
>
] can't handle large number of INSERT/UPDATEs
"Anjan Dave" <[EMAIL PROTECTED]> writes:
> One thing I am not sure is why 'bi' (disk writes) stays at 0 mostly,
> it's the 'bo' column that shows high numbe
"Anjan Dave" <[EMAIL PROTECTED]> 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 blo
7;t altered the
frequency though
Thanks,
Anjan
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 5:53 PM
To: Anjan Dave
Cc: Rod Taylor; Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
"A
"Anjan Dave" <[EMAIL PROTECTED]> writes:
> None of the locks are in state false actually.
In that case you don't have a locking problem.
> I don't have iostat on that machine, but vmstat shows a lot of writes to
> the drives, and the runnable processes are more than 1:
I get the impression that
age-
From: Matt Clark [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 2:29 PM
To: Anjan Dave
Cc: Rod Taylor; Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
>I don't have iostat on that machine, but vmstat shows a lot of w
ve
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
On Mon, 2004-10-25 at 16:53 -0400, Anjan Dave wrote:
> Hi,
>
>
>
> I am dealing with an app here that uses pg to handle a few thousand
> concurrent web users. It seems that unde
On Mon, 2004-10-25 at 16:53 -0400, Anjan Dave wrote:
> Hi,
>
>
>
> I am dealing with an app here that uses pg to handle a few thousand
> concurrent web users. It seems that under heavy load, the INSERT and
> UPDATE statements to one or two specific tables keep queuing up, to
> the count of 150+
I don't have iostat on that machine, but vmstat shows a lot of writes to
the drives, and the runnable processes are more than 1:
6 1 0 3617652 292936 279192800 0 52430 1347 4681 25
19 20 37
Assuming that's the output of 'vmstat 1' and not some other delay,
50MB/second of sus
Anjan,
> It probably is locking issue. I got a long list of locks held when we ran
> select * from pg_locks during a peak time.
Do the back-loaded tables have FKs on them? This would be a likely cause
of lock contention, and thus serializing inserts/updates to the tables.
--
--Josh
Josh B
7;t handle large number of INSERT/UPDATEs
On Tue, 2004-10-26 at 13:42, Anjan Dave wrote:
> It probably is locking issue. I got a long list of locks held when we
ran select * from pg_locks during a peak time.
>
> relation | database | transaction | pid | m
On Tue, 2004-10-26 at 13:42, Anjan Dave wrote:
> It probably is locking issue. I got a long list of locks held when we ran select *
> from pg_locks during a peak time.
>
> relation | database | transaction | pid | mode | granted
> --+--+-+---+---
of a
RAID10)
-anjan
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]
Sent: Monday, October 25, 2004 5:19 PM
To: Anjan Dave
Cc: Postgresql Performance
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
> Hi,
Subject: Re: [PERFORM] can't handle large number of INSERT/UPDATEs
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
> Hi,
>
>
>
> I am dealing with an app here that uses pg to handle a few thousand
> concurrent web users. It seems that under heavy load, the INSERT and
> UP
On Oct 25, 2004, at 13:53, Anjan Dave wrote:
I am dealing with an app here that uses pg to handle a few thousand
concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to
the count of 150+ (one table has about 432K ro
On Mon, 2004-10-25 at 16:53, Anjan Dave wrote:
> Hi,
>
>
>
> I am dealing with an app here that uses pg to handle a few thousand
> concurrent web users. It seems that under heavy load, the INSERT and
> UPDATE statements to one or two specific tables keep queuing up, to
> the count of 150+ (one
Hi,
I am dealing with an app here that uses pg to handle a few
thousand concurrent web users. It seems that under heavy load, the INSERT and
UPDATE statements to one or two specific tables keep queuing up, to the count
of 150+ (one table has about 432K rows, other has about 2.6Million r
24 matches
Mail list logo
