Re: VACUUM degrades performance significantly. Database
От | Stephen |
---|---|
Тема | Re: VACUUM degrades performance significantly. Database |
Дата | |
Msg-id | 4uDkb.4467$6k5.6@nntp-post.primus.ca обсуждение исходный текст |
Ответ на | Re: VACUUM degrades performance significantly. Database ("Dann Corbit" <DCorbit@connx.com>) |
Ответы |
Re: VACUUM degrades performance significantly. Database
|
Список | 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 по дате отправления: