Re: VACUUM degrades performance significantly. Database - Mailing list pgsql-general

From Stephen
Subject Re: VACUUM degrades performance significantly. Database
Date
Msg-id 4uDkb.4467$6k5.6@nntp-post.primus.ca
Whole thread Raw
In response to Re: VACUUM degrades performance significantly. Database  ("Dann Corbit" <DCorbit@connx.com>)
Responses Re: VACUUM degrades performance significantly. Database  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-general
Nope, I installed the RedHat 9 myself and no one else has access to this
machine. It's either that Redhat uses a different elevator setting for SCSI
drives than IDEs or the latest Redhat updates I applied brought it to my
current numbers. Besides, I believe your values may indicate an outdated
system because IIRC the max_bomb_segments has been disabled and should
always be zero because of some inefficiencies in the elevator algorithm.

Regards, Stephen


"Gaetano Mendola" <mendola@bigfoot.com> wrote in message
news:3F92EDC3.5010602@bigfoot.com...
> Stephen wrote:
>
> > Good news,
> >
> > I partially fixed the problem on Linux 2.4. It appears the
responsiveness
> > can be improved significantly by tuning the disk IO elevator in Linux
using
> > "elvtune" in util-linux. The elevator in Linux is used to re-order
> > read/write requests to reduce disk seeks by ordering requests according
to
> > disk sectors. Unfortunately, the elevator in kernel 2.4 is not very
smart
> > (or flexible I should say depending on your needs) and can starve a
> > read/write request for a long time if not properly tuned.
> > elvtune -r 2048 -w 8192 /dev/hdc (default Redhat 9):
> > ====================================================
>
> Are you sure ? In my RH9.0 installation I obtain:
>
> # elvtune /dev/sda7
>
> /dev/sda7 elevator ID           5
>          read_latency:           64
>          write_latency:          8192
>          max_bomb_segments:      6
>
>
> may be your problem is due the fact that someone change these values
> on your machine!
>
>
>
> Regards
> Gaetano Mendola
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>



pgsql-general by date:

Previous
From: "Daniel E. Fisher"
Date:
Subject: Re: Pgsql 7.3.3 on redhat 7.2
Next
From: "Joshua D. Drake"
Date:
Subject: Re: postgres 7.3.3 on redhat 7.2