Re: Problem with 8.4 stats collector high load
От | Jakub Ouhrabka |
---|---|
Тема | Re: Problem with 8.4 stats collector high load |
Дата | |
Msg-id | 4B7AEF1E.1060206@comgate.cz обсуждение исходный текст |
Ответ на | Re: Problem with 8.4 stats collector high load (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Problem with 8.4 stats collector high load
|
Список | pgsql-hackers |
> Ideally, autovacuum would only request a new copy of the file if the> one it got was considerably out of date. Obviouslya tenth of a> second is not old enough. I've tried to look at it and found that's already implemented - see autovac_refresh_stats(). STATS_READ_DELAY which is set to 1s. Am I reading the code correctly? If so then 1s is not enough for big clusters. I guess it would be feasible to crank STATS_READ_DELAY up a little bit, say to 10s. What do you think? Kuba Dne 16.2.2010 19:59, Alvaro Herrera napsal(a): > Jakub Ouhrabka wrote: >>> Maybe you should decrease naptime a bit. >> >> That did the trick, thanks! >> >>> Yes. There were some changes that needed to be done to autovacuum so >>> that it didn't read the stats file too often, but I don't recall if I >>> got around to it. >> >> I looked at the strace output and there are *writes* to the file not >> reads. Why? Is it a consequence of this optimization? >> >> Release notes 8.4: >> >> Reduce I/O load of writing the statistics collection file by writing >> the file only when requested (Martin Pihlak) >> >> Was autovacuum requesting to write this 20MB file 650x per minute? > > Yes, exactly. > > Ideally, autovacuum would only request a new copy of the file if the one > it got was considerably out of date. Obviously a tenth of a second is > not old enough. >
В списке pgsql-hackers по дате отправления: