Re: Tuning read ahead continued...

From: Ramsey Gurley <rgurley(at)smarthealth(dot)com>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Tuning read ahead continued...
Date: 2013-05-17 21:19:41
Message-ID: 3419F33F-37E3-4358-856E-36FE8B34213E@smarthealth.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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,,,,,,,,,,,,,

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?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gavin Flower 2013-05-17 21:49:42 Re: LONG delete with LOTS of FK's
Previous Message John R Pierce 2013-05-17 19:50:13 Re: Comunication protocol