Just for another data point, the default on my Debian 2.4.23-pre4 box is:
/dev/hdg elevator ID3
read_latency: 128
write_latency: 512
max_bomb_segments: 0
--
greg
---(end of
Stephen wrote:
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
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
Stephen [EMAIL PROTECTED] writes:
Dann Corbit [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
If you are always looking for exact matches, I would suggest
experimenting with a hashed index.
I already hashed the 5-way index under the column id. Removing the 5-way
index didn't
Vivek Khera wrote:
S == Stephen [EMAIL PROTECTED] writes:
S The system is actually idling when I ran the tests (load average: 0.01,
S 0.02, 0.00). When VACUUM runs, load average increases quickly (load average:
S 1.77, 0.60, 0.21) just by running psql on command line and issuing 2
S queries.
Scott,
I dropped the 5 way unique index and the VACUUM improved slightly. I ran
VACUUM, ANALYZE, VACUUM and queries repeatedly. The max response time seem
to have reduced to 1700 msec from 2300 msec. The higher load and vmstat
during VACUUM remained the same. It's still not enough to justify
S == Stephen [EMAIL PROTECTED] writes:
S The system is actually idling when I ran the tests (load average: 0.01,
S 0.02, 0.00). When VACUUM runs, load average increases quickly (load average:
S 1.77, 0.60, 0.21) just by running psql on command line and issuing 2
S queries. I've been running
index simply won't work.
-Original Message-
From: Stephen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 12:27 PM
To: [EMAIL PROTECTED]
Subject: Re: [GENERAL] VACUUM degrades performance
significantly. Database
Scott,
I dropped the 5 way unique index
Hello,
Is it normal for plain VACUUM on large table to degrade performance by over
9 times? My database becomes unusable when VACUUM runs. From reading
newsgroups, I thought VACUUM should only slow down by 10% to 15%. Other MVCC
databases like MySQL InnoDB can even VACUUM discretely (runs
Stephen [EMAIL PROTECTED] writes:
Is it normal for plain VACUUM on large table to degrade performance by over
9 times? My database becomes unusable when VACUUM runs. From reading
newsgroups, I thought VACUUM should only slow down by 10% to 15%.
We have heard reports of very significant
10 matches
Mail list logo
