Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes: TL> Bruce Momjian <[EMAIL PROTECTED]> writes: >> If we had a majority of queries filling more than one block we would >> be checkpointing like crazy and we don't normally get reports about >> that. TL> [ raised eyebrow... ] And of course the 30-second-checkpoint-warning TL> stuff is a useless feature that no one ever exercises. Well, last year about this time I discovered in my testing I was excessively checkpointing; I found that the error message was confusing, and Bruce cleaned it up. So at least one person excercised that feature, namely me. :-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-869-4449 x806 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Bruce Momjian <[EMAIL PROTECTED]> writes: > If we had a majority of queries filling more than one block we would > be checkpointing like crazy and we don't normally get reports about > that. [ raised eyebrow... ] And of course the 30-second-checkpoint-warning stuff is a useless feature that no one ever exercises. But your logic doesn't hold up anyway. People may be doing large transactions without necessarily doing them back-to-back-to-back; there could be idle time in between. For instance, I'd think an average transaction size of 100 blocks would be more than enough to make fsync a winner. There are 2K blocks per WAL segment, so 20 of these would fit in a segment. With the default WAL parameters you could do sixty such transactions per five minutes, or one every five seconds, without even causing more-frequent-than-default checkpoints; and you could do two a second without setting off the checkpoint-warning alarm. The lack of checkpoint complaints doesn't prove that this isn't a common real-world load. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: | Gaetano Mendola <[EMAIL PROTECTED]> writes: | |>Now that the argument is already open, why postgres choose |>on linux fdatasync? I'm understanding from other posts that |>on this platform open_sync is better than fdatasync. | | | AFAIR, we've seen *one* test from *one* person alleging that. | And it was definitely not that way when we tested the behavior | originally, several releases back. I'd like to see more evidence, | or better some indication that the Linux kernel changed algorithms, | before changing the default. I remember more then one person claim that open_sync *apparently* was working better then fdatasync, however I trust you ( here is 3:00 AM ). | The tests that started this thread are pretty unconvincing in my eyes, | because they are comparing open_sync against code that fsyncs after each | one-block write. Under those circumstances, *of course* fsync will lose | (or at least do no better), because it's forcing the same number of | writes through a same-or-less-efficient API. | | The reason that this isn't a trivial choice is that Postgres doesn't | necessarily need to fsync after every block of WAL. In particular, | when doing large transactions there could be many blocks written between | fsyncs, and in that case you could come out ahead with fsync because the | kernel would have more freedom to schedule disk writes. Are you suggesting that postgres shall use more the one sync method and use one or the other depending on the activity is performing ? | So, the only test I put a whole lot of faith in is testing your own | workload on your own Postgres server. But if we want to set up a toy | test program to test this stuff, it's at least got to have an easily | adjustable (and preferably randomizable) distance between fsyncs. | | Also, tests on IDE drives have zero credibility to start with, unless | you can convince me you know how to turn off write buffering on the | drive... I reported the IDE times just for info; however my SAN works better with open_sync. Can we trust on numbers given by tools/fsync ? I seen some your objections in the past but I don't know if there was some fix from that time. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBRkvW7UpzwH2SGd4RAia1AKD2L5JLhpRNvBzPq9Lv5bAfFJvRmwCffjC5 hg7V0Sfm2At7yR1C+gBCzPE= =RsSy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Tom Lane wrote: > The tests that started this thread are pretty unconvincing in my eyes, > because they are comparing open_sync against code that fsyncs after each > one-block write. Under those circumstances, *of course* fsync will lose > (or at least do no better), because it's forcing the same number of > writes through a same-or-less-efficient API. The reason that this isn't > a trivial choice is that Postgres doesn't necessarily need to fsync > after every block of WAL. In particular, when doing large transactions > there could be many blocks written between fsyncs, and in that case you > could come out ahead with fsync because the kernel would have more > freedom to schedule disk writes. My guess is that the majority of queries do not fill more than one WAL block. Sure some do, but in those cases the fsync is probably small compared to the duration of the query. If we had a majority of queries filling more than one block we would be checkpointing like crazy and we don't normally get reports about that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Gaetano Mendola <[EMAIL PROTECTED]> writes: > Now that the argument is already open, why postgres choose > on linux fdatasync? I'm understanding from other posts that > on this platform open_sync is better than fdatasync. AFAIR, we've seen *one* test from *one* person alleging that. And it was definitely not that way when we tested the behavior originally, several releases back. I'd like to see more evidence, or better some indication that the Linux kernel changed algorithms, before changing the default. The tests that started this thread are pretty unconvincing in my eyes, because they are comparing open_sync against code that fsyncs after each one-block write. Under those circumstances, *of course* fsync will lose (or at least do no better), because it's forcing the same number of writes through a same-or-less-efficient API. The reason that this isn't a trivial choice is that Postgres doesn't necessarily need to fsync after every block of WAL. In particular, when doing large transactions there could be many blocks written between fsyncs, and in that case you could come out ahead with fsync because the kernel would have more freedom to schedule disk writes. So, the only test I put a whole lot of faith in is testing your own workload on your own Postgres server. But if we want to set up a toy test program to test this stuff, it's at least got to have an easily adjustable (and preferably randomizable) distance between fsyncs. Also, tests on IDE drives have zero credibility to start with, unless you can convince me you know how to turn off write buffering on the drive... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Gaetano, > Now that the argument is already open, why postgres choose > on linux fdatasync? I'm understanding from other posts that > on this platform open_sync is better than fdatasync. Not necessarily. For example, here's my test results, on Linux 2.6.7, writing to a ReiserFS mount on a Software RAID 1 slave of 2 IDE disks, on an Athalon 1600mhz single-processor machine. I ran the loop 10,000 times instead of 1000 because tests with 1,000 varied too much. Simple write timing: write0.088701 Compare fsync times on write() and non-write() descriptor: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 3.593958 write, close, fsync 3.556978 Compare one o_sync write to two: one 16k o_sync write42.951595 two 8k o_sync writes11.251389 Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 6.807060 write, fdatasync 7.207879 write, fsync,7.209087 Compare file sync methods with 2 8k writes: (o_dsync unavailable) open o_sync, write 13.120305 write, fdatasync 7.583871 write, fsync,7.801748 -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Bruce Momjian wrote: Have you seen /src/tools/fsync? Now that the argument is already open, why postgres choose on linux fdatasync? I'm understanding from other posts that on this platform open_sync is better than fdatasync. However I choose open_sync. During initdb why don't detect this parameter ? Regards Gaetano Mendola These are my times: kernel 2.4.9-e.24smp ( RAID SCSI ): Simple write timing: write0.011544 Compare fsync times on write() and non-write() descriptor: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 1.233312 write, close, fsync 1.242086 Compare one o_sync write to two: one 16k o_sync write 0.517633 two 8k o_sync writes 0.824603 Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 0.438580 write, fdatasync 1.239377 write, fsync,1.178017 Compare file sync methods with 2 8k writes: (o_dsync unavailable) open o_sync, write 0.818720 write, fdatasync 1.395602 write, fsync,1.351214 kernel 2.4.22-1.2199.nptlsmp (single EIDE disk): Simple write timing: write0.023697 Compare fsync times on write() and non-write() descriptor: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 0.688765 write, close, fsync 0.702166 Compare one o_sync write to two: one 16k o_sync write 0.498296 two 8k o_sync writes 0.543956 Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 0.259664 write, fdatasync 0.971712 write, fsync,1.006096 Compare file sync methods with 2 8k writes: (o_dsync unavailable) open o_sync, write 0.536882 write, fdatasync 1.160347 write, fsync,1.189699 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Quoting Bruce Momjian <[EMAIL PROTECTED]>: > > Have you seen /src/tools/fsync? > I have now. Thanks. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Have you seen /src/tools/fsync? --- [EMAIL PROTECTED] wrote: > Hi, I'd like to help with the topic in the Subject: line. It seems to be a > TODO item. I've reviewed some threads discussing the matter, so I hope I've > acquired enough history concerning it. I've taken an initial swipe at > figuring out how to optimize sync'ing methods. It's based largely on > recommendations I've read on previous threads about fsync/O_SYNC and so on. > After reviewing, if anybody has recommendations on how to proceed then I'd > love to hear them. > > Attached is a little program that basically does a bunch of sequential writes > to a file. All of the sync'ing methods supported by PostgreSQL WAL can be > used. Results are printed in microseconds. Size and quanity of writes are > configurable. The documentation is in the code (how to configure, build, run, > etc.). I realize that this program doesn't reflect all of the possible > activities of a production database system, but I hope it's a step in the > right direction for this task. I've used it to see differences in behavior > between the various sync'ing methods on various platforms. > > Here's what I've found running the benchmark on some systems to which > I have access. The differences in behavior between platforms is quite vast. > > Summary first... > > > PostgreSQL should be run on an old Apple MacIntosh attached to > its own Hitachi disk array with 2GB cache or so. Use any sync method > except for fsync(). > > > Anyway, there is *a lot* of variance in file synching behavior across > different hardware and O/S platforms. It's probably not safe > to conclude much. That said, here are some findings so far based on > tests I've run: > > 1. under no circumstances do fsync() or fdatasync() seem to perform > better than opening files with O_SYNC or O_DSYNC > 2. where there are differences, opening files with O_SYNC or O_DSYNC > tends to be quite faster. > 3. fsync() seems to be the slowest where there are differences. And > O_DSYNC seems to be the fastest where results differ. > 4. the safest thing to assert at this point is that > Solaris systems ought to use the O_DSYNC method for WAL. > > --- > > Test system(s) > > Athlon Linux: > AMD Athlon XP2000, 512MB RAM, single (54 or 7200?) RPM 20GB IDE disk, > reiserfs filesystem (3 something I think) > SuSE Linux kernel 2.4.21-99 > > Mac Linux: > I don't know the specific model. 400MHz G3, 512MB, single IDE disk, > ext2 filesystem > Debian GNU/Linux 2.4.16-powerpc > > HP Intel Linux: > Prolient HPDL380G3, 2 x 3GHz Xeon, 2GB RAM, SmartArray 5i 64MB cache, > 2 x 15,000RPM 36GB U320 SCSI drives mirrored. I'm not sure if > writes are cached or not. There's no battery backup. > ext3 filesystem. > Redhat Enterprise Linux 3.0 kernel based on 2.4.21 > > Dell Intel OpenBSD: > Poweredge ?, single 1GHz PIII, 128MB RAM, single 7200RPM 80GB IDE disk, > ffs filesystem > OpenBSD 3.2 GENERIC kernel > > SUN Ultra2: > Ultra2, 2 x 296MHz UltraSPARC II, 2GB RAM, 2 x 10,000RPM 18GB U160 > SCSI drives mirrored with Solstice DiskSuite. UFS filesystem. > Solaris 8. > > SUN E4500 + HDS Thunder 9570v > E4500, 8 x 400MHz UltraSPARC II, 3GB RAM, > HDS Thunder 9570v, 2GB mirrored battery-backed cache, RAID5 with a > bunch of 146GB 10,000RPM FC drives. LUN is on single 2GB FC fabric > connection. > Veritas filesystem (VxFS) > Solaris 8. > > Test methodology: > > All test runs were done with CHUNKSIZE 8 * 1024, CHUNKS 2 * 1024, > FILESIZE_MULTIPLIER 2, and SLEEP 5. So a total of 16MB was sequentially > written for each benchmark. > > Results are in microseconds. > > PLATFORM: Athlon Linux > buffered: 48220 > fsync: 74854397 > fdatasync: 75061357 > open_sync: 73869239 > open_datasync: 74748145 > Notes: System mostly idle. Even during tests, top showed about 95% > idle. Something's not right on this box. All sync methods similarly > horrible on this system. > > PLATFORM: Mac Linux > buffered: 58912 > fsync: 1539079 > fdatasync: 769058 > open_sync: 767094 > open_datasync: 763074 > Notes: system mostly idle. fsync seems worst. Otherwise, they seem > pretty equivalent. This is the fastest system tested. > > PLATFORM: HP Intel Linux > buffered: 33026 > fsync: 29330067 > fdatasync: 28673880 > open_sync: 8783417 > open_datasync: 8747971 > Notes: system idle. O_SYNC and O_DSYNC methods seem to be a lot > better on this platform than fsync & fdatasync. > > PLATFORM: Dell Intel OpenBSD > buffer
