Re: Tuning read ahead continued... - Mailing list pgsql-general
On May 16, 2013, at 5:56 PM, Ramsey Gurley wrote:
Hi All,
I tried bumping my read ahead up to 4096. Instead of having faster reads, it seems it actually slowed things down. In fact, most of the tuning suggestions I've tried have made little to no difference in the results I get from bonnie++.
I've run more tests with bonnie++. I'm beginning to wonder if there's something wrong with my system or my setup. In every test I have run, Seq Reads is faster with read ahead set to 256. If I increase read ahead to 4096 as suggested in Postgresql 9.0 High Performance, I get slower reads and slower writes.
Other settings I've made as suggested by the book,
/dev/sdb1 / ext3 noatime,errors=remount-ro 0 1
vm.swappiness=0
vm.overcommit_memory=2
echo 2 > /proc/sys/vm/dirty_ratio
echo 1 > /proc/sys/vm/dirty_background_ratio
Here is 4096 read ahead
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
498088-db1.s 96280M 130123 24 103634 15 277467 14 652.4 1
498088-db1.smarthealth.com,96280M,,,130123,24,103634,15,,,277467,14,652.4,1,,,,,,,,,,,,,
And here is the default 256 read ahead
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
498088-db1.s 96280M 160881 28 104868 17 286109 17 591.9 0
498088-db1.smarthealth.com,96280M,,,160881,28,104868,17,,,286109,17,591.9,0,,,,,,,,,,,,,
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
498088-db1.s 96280M 160881 28 104868 17 286109 17 591.9 0
498088-db1.smarthealth.com,96280M,,,160881,28,104868,17,,,286109,17,591.9,0,,,,,,,,,,,,,
I also made some zcav plots. They are very flat on 256, which seems to indicate some limiting factor, but they also appear to be consistently *higher* than the 4096 values after about 70GB.
Does this look familiar to anyone?
Attachment
pgsql-general by date: