0

Up to now it takes one hour to run all tests of our software which is build with this components: Linux, PostgreSQL, Python, Django

I guess the performance could be improved if we fake fsync calls.

PostgreSQL has the option to disable fsync, but wouldn't it be better to tell the whole operating system to delay fsync as much as it can?

Update: I know that this is unsafe and a server crash could make the system unrecoverable. But this is a unimportant jenkins slave, which can be set up again fast.

Update2: PostgreSQL is just one of many services running on that host. I search a solution on operating system level.

guettli
  • 26,461
  • 53
  • 224
  • 476
  • That seems like a bad idea. A DBMS *needs* (a certain amount of) ordered writes to allow crash recovery. – wildplasser Jan 29 '14 at 13:40
  • @wildplasser I updated the question: The server is an unimportant jenkins slave. No problem, if unrecoverable. – guettli Jan 29 '14 at 14:27
  • 1
    Turning off fsync on postgresql is probably going to get you 99+% of the benefit there is to be had. It hardly seems worthwhile to worry about the other <1%. You could put the whole thing on /dev/shm/ if it will fit. – jjanes Jan 29 '14 at 17:09
  • @jjanes PostgreSQL is just one of several applications which produce IO load during testing. I turned off synchronous commits and increased the wal_writer_delay to 2000ms, but this does not help much. I guess the PostgreSQL IO is less important in my setup. That's why I want to tune fsync at OS level. – guettli Jan 29 '14 at 19:48
  • Is there some missing context here? Why do you think that "faking fsync" will help what you're doing? `fsync()` should only be flushing the target file(s). Is some other process on the system doing a global `sync()` call, maybe? Personally I strongly suggest using `UNLOGGED` tables instead of disabling `fsync`. – Craig Ringer Jan 30 '14 at 01:24
  • @Craig, Yeah, I don't understand what other than a database would be issuing many fsyncs in the first place. But I don't think UNLOGGED would work, the transaction will still issue a commit record (at least under hot_standby--haven't tested lower levels) and that will get fsynced. Would have to turn off synchronous_commit. – jjanes Feb 04 '14 at 17:14
  • @jjanes Good point. I was thinking in terms of it being volume of data flushed, but it's probably a spinning rust drive that can only do in range of two digits of fsyncs per second. – Craig Ringer Feb 04 '14 at 23:22

0 Answers0