Обсуждение: fsync and battery-backed caches

Javier Somoza schrieb:
>
>         Hi all
>
>         Is it secure to disable fsync havin battery-backed disk cache?
>
>         Thx
>
No. fsync moves the data from OS memory cache to disk-adaptor
cache which is required to benefit from battery backup.

If this data is written to the plates immediately depends on settings
of your disk adaptor card.

Regards
Tino

On Mon, Feb 27, 2006 at 11:12:57AM +0100, Tino Wildenhain wrote:
> Javier Somoza schrieb:
> >
> >        Hi all
> >
> >        Is it secure to disable fsync havin battery-backed disk cache?
> >
> >        Thx
> >
> No. fsync moves the data from OS memory cache to disk-adaptor
> cache which is required to benefit from battery backup.

More importantly, in guarantees that data is committed to non-volatile
storage in such a way that PostgreSQL can recover from a crash without
corruption.

If you have a battery-backed controller and turn on write caching you
shouldn't see much effect from fsync anyway.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

Jim C. Nasby wrote:
> On Mon, Feb 27, 2006 at 11:12:57AM +0100, Tino Wildenhain wrote:
> > Javier Somoza schrieb:
> > >
> > >        Hi all
> > >
> > >        Is it secure to disable fsync havin battery-backed disk cache?
> > >
> > >        Thx
> > >
> > No. fsync moves the data from OS memory cache to disk-adaptor
> > cache which is required to benefit from battery backup.
>
> More importantly, in guarantees that data is committed to non-volatile
> storage in such a way that PostgreSQL can recover from a crash without
> corruption.
>
> If you have a battery-backed controller and turn on write caching you
> shouldn't see much effect from fsync anyway.

We do mention battery-backed cache in our docs:

    http://www.postgresql.org/docs/8.1/static/wal.html

If it is unclear, please let us know.

--
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +

We do mention battery-backed cache in our docs:
http://www.postgresql.org/docs/8.1/static/wal.html

If it is unclear, please let us know.

Javier Somoza

Oficina de Dirección Estratégica

mailto:jsomoza@pandasoftware.es



Panda Software

Buenos Aires, 12

48001 BILBAO - ESPAÑA

Teléfono: 902 24 365 4

Fax:  94 424 46 97

http://www.pandasoftware.es

Panda Software, una de las principales compañías desarrolladoras de soluciones de protección contra virus e intrusos, presenta su nueva familia de soluciones. Todos los usuarios de ordenadores, desde las redes más grandes a los domésticos, disponen ahora de nuevos productos con excelentes tecnologías de seguridad. Más información en: http://www.pandasoftware.es/productos
   


¡Protéjase ahora contra virus e intrusos! Pruebe gratis nuestros productos en http://www.pandasoftware.es/descargas/
   
       
       
   
   
   
   
   
   
   

Hi,
is interesting to do it when using RAID 1+0?
Thx

At 04:45 AM 2/28/2006, Javier Somoza wrote:

>Hi,
>is interesting to do it (use different HD sets AKA "LUNs" for xlogs
>than for data) when using RAID 1+0?

If "interesting" means "this increases performance", this is not a
simple question.

Regardless of what RAID level you use, under the proper circumstances
it can boost performance to put xlog on a dedicated set of spindles.

If you have a large enough pool of HDs so that you can maximize the
performance of any LUN you create, then it is always good to put xlog
on its own LUN.

In the "perfect" world, each table or set of tables that tends to be
accessed for the same query, which obviously includes xlog, would be
on its own LUN; and each LUN would contain enough HDs to maximize performance.

Most people can't afford and/or fit that many HDs into their set up.

If you have a small number of HDs, and "small" depends on the
specifics of your DB and the HDs you are using, you may get better
performance by leaving everything together on one set of HDs.

Once you have more than whatever is a "small" number of HDs for your
DB and set of disks, _usually_, but not always, one of the best first
tables to move to different HD's is xlog.

The best way to find out what will get the most performance from your
specific HW and DB is to test, test, test.  Start by putting
everything on 1 RAID 5 set.  Test.  Then (if you have enough HDs) put
everything on 1 RAID 1+0 set.  Test again.  If performance is "good
enough", and only you know what that is for your DB, then STOP and
just use whichever works best for you.  It's possible to spend far
more money in man hours of effort than it is worth trying to get a
few extra percents of performance.

If you have the need and the budget to tweak things further, then
start worrying about the more complicated stuff.

As a rule of thumb, figure each 7200rpm HD does ~50MBps and each
15Krpm (or 10Krpm WD Raptor) does ~75MBps.  So a 8 HD RAID 5 set of
7200rpm HDs does ~(8-1= 7)*50= ~350MBps. A RAID 10 set made of the
same 8 HDs should do ~4*50= 200MBps.  (=If and only if= the rest of
your HW let's the RAID set push data at that speed.).  Also, note
that RAID 5 writes are often 2/3 - 4/5 the speed of RAID 5 reads.

If we pull 1 HD from the 8 HD RAID 5 set above and dedicate it to
xlog, then xlog will always get ~50MBps bandwidth.  OTOH, in the
original RAID 5 configuration xlog was probably sharing between 2/3
and 4/5 of ~350MBps bandwidth.  Say ~233-280MBps.  Which results in
higher overall performance for you DB?  Only testing by you on your
DB can tell.

Hope this helps,
Ron

Actually, you can't assume that a BBU means you can safely disable
full-page-writes. Depending on the controller, it's still possible to
end up with partially written pages.

BTW, if your mailer makes doing so convenient, it would be nice to trim
down your .signature; note that it's about 3x longer than the email you
actually sent.

On Tue, Feb 28, 2006 at 09:19:36AM +0100, Javier Somoza wrote:
>
>             Yeah, i saw it. It says full-page-writes can be disabled
> without problems.
>             But i wanted to confirm fsync cannot be disabled although i
> have battery.
>
>             Thanks!!   :-)
>
>
>
> > We do mention battery-backed cache in our docs:
> >
> >     http://www.postgresql.org/docs/8.1/static/wal.html
> >
> > If it is unclear, please let us know.
>
> Javier Somoza
> Oficina de Direcci?n Estrat?gica
> mailto:jsomoza@pandasoftware.es
>
> Panda Software
> Buenos Aires, 12
> 48001 BILBAO - ESPA?A
> Tel?fono: 902 24 365 4
> Fax:  94 424 46 97
> http://www.pandasoftware.es
> Panda Software, una de las principales compa??as desarrolladoras de
> soluciones de protecci?n contra virus e intrusos, presenta su nueva
> familia de soluciones. Todos los usuarios de ordenadores, desde las
> redes m?s grandes a los dom?sticos, disponen ahora de nuevos productos
> con excelentes tecnolog?as de seguridad. M?s informaci?n en:
> http://www.pandasoftware.es/productos
>
>
>
> ?Prot?jase ahora contra virus e intrusos! Pruebe gratis nuestros
> productos en http://www.pandasoftware.es/descargas/
>
>
>
>
>
>
>
>
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

Actually, you can't assume that a BBU means you can safely disable
full-page-writes. Depending on the controller, it's still possible to
end up with partially written pages.

BTW, if your mailer makes doing so convenient, it would be nice to trim
down your .signature; note that it's about 3x longer than the email you
actually sent.

Ok, you absolutely can't guarantee you won't get partial page writes
then. A UPS buys you no more data safety than being plugged directly
into the wall. UPS's fail. People trip over cords. Breakers fail. Even
if you have multiple power supplies on multiple circuits fed by
different UPS's you can *still* have unexpected power failures. The
'master' for distributed.net had exactly that happen recently; the two
breakers feeding it (from 2 seperate UPS's) failed simultaneously.

In a nutshell, having a server on a UPS is notthing at all like having a
BBU on the raid controller: commiting to the BBU is essentially the same
as committing to the drives, unless the BBU runs out of power before the
server has power restored, or fails in some similar fasion. But because
there's many fewer parts involved, such a failure of the BBU is far less
likely than a failure up-stream.

So, if you want performance, get a controller with a BBU and allow it to
cache writes. While you're at it, try and get one that will
automatically disable write caching if the BBU fails for some reason.

On Tue, Feb 28, 2006 at 06:27:34PM +0100, Javier Somoza wrote:
>
>             Ups sorry.
>
>
> > Actually, you can't assume that a BBU means you can safely disable
> > full-page-writes. Depending on the controller, it's still possible to
> > end up with partially written pages.
> >
> > BTW, if your mailer makes doing so convenient, it would be nice to trim
> > down your .signature; note that it's about 3x longer than the email you
> > actually sent.
>
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461