From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Piggybacking vacuum I/O |
Date: | 2007-01-25 09:01:58 |
Message-ID: | 2e78013d0701250101l5ef6a00eqa831b78ab7cfa75f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/24/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>
> Pavan Deolasee wrote:
> > I have just counted the number of read/write calls on the CLOG blocks.
> As
> > you can
> > see the total number of CLOG reads jumped from 545323 to 1181851 i.e.
> > 1181851 - 545323 = 636528 CLOG block reads for 1554697 pages of stock
> > table.
>
> Hmm. So there is some activity there. Could you modify the patch to
> count how many of those reads came from OS cache? I'm thinking of doing
> a gettimeofday() call before and after read, and counting how many
> calls finished in less than say < 1 ms. Also, summing up the total time
> spent in reads would be interesting.
Here are some more numbers. I ran two tests of 4 hour each with CLOG cache
size set to 8 blocks (default) and 16 blocks. I counted the number of read()
calls
and specifically those read() calls which took more than 0.5 ms to complete.
As you guessed, almost 99% of the reads complete in less than 0.5 ms, but
the total read() time is still more than 1% of the duration of the test. Is
it
worth optimizing ?
CLOG (16 blocks)
reads(743317), writes(84), reads > 0.5 ms (5171), time reads (186s), time
reads > 0.5 ms(175s)
CLOG (8 blocks)
reads(1155917), writes(119), reads > 0.5 ms (4040), time reads (146s), time
reads > 0.5 ms(130s)
(amused to see increase in the total read time with 16 blocks)
Also is it worth optimizing on the total read() system calls which might not
cause physical I/O, but
still consume CPU ?
Thanks,
Pavan
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2007-01-25 09:14:51 | Re: "tupdesc reference is not owned by resource owner Portal" |
Previous Message | Oleg Bartunov | 2007-01-25 07:51:42 | Re: tsearch in core patch, for inclusion |