Re: Linux kernel impact on PostgreSQL performance
От | Jim Nasby |
---|---|
Тема | Re: Linux kernel impact on PostgreSQL performance |
Дата | |
Msg-id | 52D5D4DC.2010902@nasby.net обсуждение исходный текст |
Ответ на | Re: Linux kernel impact on PostgreSQL performance (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Linux kernel impact on PostgreSQL performance
|
Список | pgsql-hackers |
On 1/14/14, 11:30 AM, Jeff Janes wrote: > I think the "reclaim this page if you need memory but leave it resident if there is no memory pressure" hint would be moreuseful for temporary working files than for what was being discussed above (shared buffers). When I do work that needslarge temporary files, I often see physical write IO spike but physical read IO does not. I interpret that to meanthat the temporary data is being written to disk to satisfy either dirty_expire_centisecs or dirty_*bytes, but the dataremains in the FS cache and so disk reads are not needed to satisfy it. So a hint that says "this file will never befsynced so please ignore dirty_*bytes and dirty_expire_centisecs. I will need it again relatively soon (but not aftera reboot), but will do so mostly sequentially, so please don't evict this without need, but if you do need to then itis a good candidate" would be good. I also frequently see this, and it has an even larger impact if pgsql_tmp is on the same filesystem as WAL. Which *theoretically*shouldn't matter with a BBU controller, except that when the kernel suddenly decides your *temporary* dataneeds to hit the media you're screwed. Though, it also occurs to me... perhaps it would be better for us to simply map temp objects to memory and let the kernelswap them out if needed... -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: