Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
От | Jan Wieck |
---|---|
Тема | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |
Дата | |
Msg-id | 4023ADCE.5000802@Yahoo.com обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
|
Список | pgsql-hackers |
Tom Lane wrote: > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: >> So Imho the target should be to have not much IO open for the checkpoint, >> so the fsync is fast enough, even if serial. > > The best we can do is push out dirty pages with write() via the bgwriter > and hope that the kernel will see fit to write them before checkpoint > time arrives. I am not sure if that hope has basis in fact or if it's > just wishful thinking. Most likely, if it does have basis in fact it's > because there is a standard syncer daemon forcing a sync() every thirty > seconds. Looking at the response time charts I did for showing how vacuum delay is doing, it seems at least on Linux there is hope that that is the case. Those charts have just a regular 5 minute checkpoint with enough checkpoint segments for that, and no other sync effort done at all. The system has a hard time to handle a larger scaled test DB, so it is definitely well saturated with IO. The charts are here: http://developer.postgresql.org/~wieck/vacuum_cost/ > > That means that instead of an I/O storm every checkpoint interval, > we get a smaller I/O storm every 30 seconds. Not sure this is a big > improvement. Jan already found out that issuing very frequent sync()s > isn't a win. In none of those charts I can see any checkpoint caused IO storm any more. Charts I'm currently doing for 7.4.1 show extremely clear spikes at checkpoints. If someone is interested in those as well I will put them up. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: