Greg Smith wrote:
On Fri, 29 Feb 2008, Franck Routier wrote:
my Raid controller is an Adaptec 31205 SAS/RAID controller. The battery
was an option, but I didn't know it at purchase time. So I have no
battery, but the whole system is on an UPS.
The UPS is of no help here. The problem is that PostgreSQL forces the
disk controller to commit WAL writes to disk after every transaction.
If you have a controller with a battery-backed cache, you can use that
cache to buffer those writes and dramatically increase write
performance. The USP doesn't give you the same write guarantees. Let's
say someone trips over the server power cord (simplest example of a
whole class of failures). With the BBC controller, the cached writes
will get committed when you plug the server back in. If all you've got
is a UPS, writes that didn't make it to disk before the outage are
lost. That means you can't buffer those writes without risking database
corruption.
The general guideline here is that if you don't have a battery-backed
cache on your controller, based on disk rotation speed you'll be limited
to around 100 (7200 RPM) to 200 (15K RPM) commits/second per single
client, with each commit facing around a 2-4ms delay. That rises to
perhaps 500/s total with lots of clients. BBC configurations can easily
clear 3000/s total and individual commits don't have that couple of ms
delay.
It may be the way you have worded this but it makes it sound like the
cache and the battery backup are as one (or that the cache doesn't work
unless you have the battery) The cache may be optional (or plug-in) in
some cards, even of varied size. The battery is normally optional. You
can normally add/remove the battery without changing the cache options.
If the raid card has the cache without the battery you would get the
performance figures you mentioned, you just wouldn't have the
reliability of finishing writes after a power off situation.
correct me if I am wrong here.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly