Re: new server I/O setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Mensaje original-----
> De: Greg Smith
> 
>> Fernando Hevia wrote: 
>> 
>> 	I justified my first choice in that WAL writes are 
>> sequentially and OS pretty much are too, so a RAID 1 probably 
>> would hold ground against a 12 disc RAID 10 with random writes.
>> 
> 
> The problem with this theory is that when PostgreSQL does WAL 
> writes and asks to sync the data, you'll probably discover 
> all of the open OS writes that were sitting in the Linux 
> write cache getting flushed before that happens.  And that 
> could lead to horrible performance--good luck if the database 
> tries to do something after cron kicks off updatedb each 
> night for example.
> 

I actually hadn't considered such a scenario. It probably wont hit us
because our real-time activity diminishes abruptly overnight when
maintainance routines kick in.
But in case this proves to be an issue, disabling synchronous_commit should
help out, and thanks to the BBU cache the risk of lost transactions should
be very low. In any case I would leave it on till the issue arises. Do you
agree?

In our business worst case situation could translate to losing a couple
seconds worth of call records, all recoverable from secondary storage.


> I think there are two viable configurations you should be 
> considering you haven't thought about:
> , but neither is quite what you're looking at:
> 
> 2 discs in RAID 1 for OS
> 2 discs in RAID 1 for pg_xlog
> 10 discs in RAID 10 for postgres, ext3
> 2 spares.
> 
> 14 discs in RAID 10 for everything
> 2 spares.
> 
> Impossible to say which of the four possibilities here will 
> work out better.  I tend to lean toward the first one I 
> listed above because it makes it very easy to monitor the 
> pg_xlog activity (and the non-database activity) separately 
> from everything else, and having no other writes going on 
> makes it very unlikely that the pg_xlog will ever become a 
> bottleneck.  But if you've got 14 disks in there, it's 
> unlikely to be a bottleneck anyway.  The second config above 
> will get you slightly better random I/O though, so for 
> workloads that are really limited on that there's a good 
> reason to prefer it.
> 

Beside the random writing, we have quite intensive random reads too. I need
to maximize throughput on the RAID 10 array and it makes me feel rather
uneasy the thought of taking 2 more disks from it.
I did consider the 14 disks RAID 10 for all since it's very attractive for
read I/O. But with 12 spins read I/O should be incredibly fast for us
considering our current production server has a meager 4 disk raid 10.
I still think the 2d RAID 1 + 12d RAID 10 will be the best combination for
write throughput, providing the RAID 1 can keep pace with the RAID 10,
something Scott already confirmed to be his experience.

> Also:  the whole "use ext2 for the pg_xlog" idea is overrated 
> far as I'm concerned.  I start with ext3, and only if I get 
> evidence that the drive is a bottleneck do I ever think of 
> reverting to unjournaled writes just to get a little speed 
> boost.  In practice I suspect you'll see no benchmark 
> difference, and will instead curse the decision the first 
> time your server is restarted badly and it gets stuck at fsck.
> 

This advice could be interpreted as "start safe and take risks only if
needed"
I think you are right and will follow it.

>> 	Pd: any clue if hdparm works to deactive the disks 
>> write cache even if they are behind the 3ware controller?
>> 	
> 
> You don't use hdparm for that sort of thing; you need to use 
> 3ware's tw_cli utility.  I believe that the individual drive 
> caches are always disabled, but whether the controller cache 
> is turned on or not depends on whether the card has a 
> battery.  The behavior here is kind of weird though--it 
> changes if you're in RAID mode vs. JBOD mode, so be careful 
> to look at what all the settings are.  Some of these 3ware 
> cards default to extremely aggressive background scanning for 
> bad blocks too, you might have to tweak that downward too.
> 

It has a battery and it is working in RAID mode. 
It's also my first experience with a hardware controller. Im installing
tw_cli at this moment.

Greg, I hold your knowledge in this area in very high regard. 
Your comments are much appreciated.


Thanks,
Fernando


-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux