Thread: fsync and battery-backed caches
Hi all
Is it secure to disable fsync havin battery-backed disk cache?
Thx
| 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 |
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. +
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 |
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
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.
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