pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedwal sync method
6+ messages / 5 participants
[nested] [flat]
* wal sync method
@ 2006-02-27 12:08 Evgeny Gridasov <eugrid@fpm.kubsu.ru>
0 siblings, 1 reply; 6+ messages in thread
From: Evgeny Gridasov @ 2006-02-27 12:08 UTC (permalink / raw)
To: pgsql-performance
Hi everybody!
Which wal sync method is the fastest under linux 2.6.x?
I'm using RAID-10 (JFS filesystem), 2xXEON, 4 Gb RAM.
I've tried to switch to open_sync which seems to work
faster than default fdatasync, but is it crash-safe?
--
Evgeny Gridasov
Software Engineer
I-Free, Russia
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: wal sync method
@ 2006-02-27 12:29 Javier Somoza <jsomoza@pandasoftware.es>
parent: Evgeny Gridasov <eugrid@fpm.kubsu.ru>
0 siblings, 1 reply; 6+ messages in thread
From: Javier Somoza @ 2006-02-27 12:29 UTC (permalink / raw)
To: Evgeny Gridasov <eugrid@fpm.kubsu.ru>; +Cc: pgsql-performance
Hi Evgeny
Im also testing what fsync method to use and using this program
(http://archives.postgresql.org/pgsql-performance/2003-12/msg00191.php)
a bit modified and i get this results:
write 0.000036
write & fsync 0.006796
write & fdatasync 0.001001
write (O_FSYNC) 0.005761
write (O_DSYNC) 0.005894
So fdatasync faster for me?
> Hi everybody!
>
> Which wal sync method is the fastest under linux 2.6.x?
> I'm using RAID-10 (JFS filesystem), 2xXEON, 4 Gb RAM.
>
> I've tried to switch to open_sync which seems to work
> faster than default fdatasync, but is it crash-safe?
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/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: wal sync method
@ 2006-02-28 01:14 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Javier Somoza <jsomoza@pandasoftware.es>
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Momjian @ 2006-02-28 01:14 UTC (permalink / raw)
To: Javier Somoza <jsomoza@pandasoftware.es>; +Cc: Evgeny Gridasov <eugrid@fpm.kubsu.ru>; pgsql-performance
Use whichever sync method is fastest for you. They are all reliable,
except turning fsync off.
---------------------------------------------------------------------------
Javier Somoza wrote:
>
>
>
> Hi Evgeny
>
> Im also testing what fsync method to use and using this program
> (http://archives.postgresql.org/pgsql-performance/2003-12/msg00191.php)
> a bit modified and i get this results:
>
> write 0.000036
> write & fsync 0.006796
> write & fdatasync 0.001001
> write (O_FSYNC) 0.005761
> write (O_DSYNC) 0.005894
>
> So fdatasync faster for me?
>
>
> > Hi everybody!
> >
> > Which wal sync method is the fastest under linux 2.6.x?
> > I'm using RAID-10 (JFS filesystem), 2xXEON, 4 Gb RAM.
> >
> > I've tried to switch to open_sync which seems to work
> > faster than default fdatasync, but is it crash-safe?
>
>
>
>
> 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/
>
>
>
>
>
>
>
>
>
--
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. +
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: wal sync method
@ 2006-02-28 23:31 PFC <lists@peufeu.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: PFC @ 2006-02-28 23:31 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; Javier Somoza <jsomoza@pandasoftware.es>; +Cc: Evgeny Gridasov <eugrid@fpm.kubsu.ru>; pgsql-performance
Just a stupid question about the various fsync settings.
There is fsync=off, but is there fsync=fflush ?
fflush would mean only an OS crash could cause data loss,
I think.it could be useful for some applications where you need a speed
boost (like testing database import scripts...) without being as scary as
fsync=off...
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: wal sync method
@ 2006-02-28 23:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: PFC <lists@peufeu.com>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2006-02-28 23:45 UTC (permalink / raw)
To: PFC <lists@peufeu.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Javier Somoza <jsomoza@pandasoftware.es>; Evgeny Gridasov <eugrid@fpm.kubsu.ru>; pgsql-performance
PFC <lists@peufeu.com> writes:
> Just a stupid question about the various fsync settings.
> There is fsync=off, but is there fsync=fflush ?
> fflush would mean only an OS crash could cause data loss,
> I think.it could be useful for some applications where you need a speed
> boost (like testing database import scripts...) without being as scary as
> fsync=off...
I think you misunderstand. There aren't any scenarios where a PG crash
(without hardware/OS crash) risks data, because we always at least
write() data before commit. The only issue is how hard do we try to get
the OS+hardware to push that data down to disk.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: wal sync method
@ 2006-03-01 11:58 PFC <lists@peufeu.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: PFC @ 2006-03-01 11:58 UTC (permalink / raw)
To: pgsql-performance
Hm, i seem to have mixed fwrite() (which buffers data in userspace) and
write() (which apparently doesnt !)
Sorry !
> PFC <lists@peufeu.com> writes:
>> Just a stupid question about the various fsync settings.
>> There is fsync=off, but is there fsync=fflush ?
>> fflush would mean only an OS crash could cause data loss,
>> I think.it could be useful for some applications where you need a speed
>> boost (like testing database import scripts...) without being as scary
>> as
>> fsync=off...
>
> I think you misunderstand. There aren't any scenarios where a PG crash
> (without hardware/OS crash) risks data, because we always at least
> write() data before commit. The only issue is how hard do we try to get
> the OS+hardware to push that data down to disk.
>
> regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2006-03-01 11:58 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-02-27 12:08 wal sync method Evgeny Gridasov <eugrid@fpm.kubsu.ru>
2006-02-27 12:29 ` Javier Somoza <jsomoza@pandasoftware.es>
2006-02-28 01:14 ` Bruce Momjian <pgman@candle.pha.pa.us>
2006-02-28 23:31 ` PFC <lists@peufeu.com>
2006-02-28 23:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-03-01 11:58 ` PFC <lists@peufeu.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox