Re: checkpointer continuous flushing - V18
От | Fabien COELHO |
---|---|
Тема | Re: checkpointer continuous flushing - V18 |
Дата | |
Msg-id | alpine.DEB.2.10.1603080826300.16765@sto обсуждение исходный текст |
Ответ на | Re: checkpointer continuous flushing - V18 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: checkpointer continuous flushing - V18
|
Список | pgsql-hackers |
Hello Andres, >> Now I cannot see how having one context per table space would have a >> significant negative performance impact. > > The 'dirty data' etc. limits are global, not per block device. By having > several contexts with unflushed dirty data the total amount of dirty > data in the kernel increases. Possibly, but how much? Do you have experimental data to back up that this is really an issue? We are talking about 32 (context size) * #table spaces * 8KB buffers = 4MB of dirty buffers to manage for 16 table spaces, I do not see that as a major issue for the kernel. > Thus you're more likely to see stalls by the kernel moving pages into > writeback. I do not see the above data having a 30% negative impact on tps, given the quite small amount of data under discussion, and switching to random IOs cost so much that it must really be avoided. Without further experimental data, I still think that the one context per table space is the reasonnable choice. -- Fabien.
В списке pgsql-hackers по дате отправления: