Re: "pgstat wait timeout" warnings
От | Heikki Linnakangas |
---|---|
Тема | Re: "pgstat wait timeout" warnings |
Дата | |
Msg-id | 4E42D3CE.3090906@enterprisedb.com обсуждение исходный текст |
Ответ на | "pgstat wait timeout" warnings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "pgstat wait timeout" warnings
|
Список | pgsql-hackers |
On 10.08.2011 21:45, Tom Lane wrote: > We occasionally see $SUBJECT in the buildfarm, and I've also recently > had reports of them from Red Hat customers. The obvious theory is that > these reflect high load preventing the stats collector from responding, > but it would really take pretty crushing load to make that happen if > there were not anything funny going on. > > It struck me just now while reviewing the latch code that pg_usleep > could sleep for less than the expected time if a signal happened, and > if that happened repeatedly for some reason, perhaps the loop could > complete in much less than the nominal time. I'm not sure I believe > that idea either, but anyway I'm feeling motivated to try to gather more > data. I've also seen this on my laptop occasionally. The most recent case I remember was when I COPYed a lot of data, so that the harddisk was really busy. The system was a bit unresponsive anyway, because of all the I/O happening. So my theory is that if the I/O is really busy, write() on the stats file blocks for more than 5 seconds, and you get the timeout. > Does anyone have a problem with sticking a lot of debugging printout > into backend_read_statsfile() in HEAD only? I'm envisioning it starting > to dump assorted information including elapsed time, errno values, etc > once the loop counter is more than halfway to expiration, which is > already a situation that we shouldn't see under normal conditions. No objections here. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: