Tuning read ahead continued...

Started by Ramsey Gurleyalmost 13 years ago2 messagesgeneral
Jump to latest
#1Ramsey Gurley
rgurley@smarthealth.com

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'll include a table of values in html. I'm wondering if these are normal values in my case; 4 disk RAID10 Linux ext3 146GB SAS 15K RPM Drive.

Attachments:

benchmarks.htmltext/html; name=benchmarks.htmlDownload
#2Ramsey Gurley
rgurley@smarthealth.com
In reply to: Ramsey Gurley (#1)
Re: Tuning read ahead continued...

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,,,,,,,,,,,,,

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?

Attachments:

sdb1-256.pngimage/png; name=sdb1-256.png; x-unix-mode=0644Download
sdb1-4096.pngimage/png; name=sdb1-4096.png; x-unix-mode=0644Download