Re: Occasional giant spikes in CPU load
От | Craig James |
---|---|
Тема | Re: Occasional giant spikes in CPU load |
Дата | |
Msg-id | 4C24D679.7030701@emolecules.com обсуждение исходный текст |
Ответ на | Re: Occasional giant spikes in CPU load (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Occasional giant spikes in CPU load
Re: Occasional giant spikes in CPU load Re: Occasional giant spikes in CPU load |
Список | pgsql-performance |
On 6/25/10 7:47 AM, Tom Lane wrote: > Craig James<craig_james@emolecules.com> writes: >> On 6/24/10 9:04 PM, Tom Lane wrote: >>> sinval queue overflow comes to mind ... although that really shouldn't >>> happen if there's "no real load" on the server. What PG version is >>> this? > >> 8.3.10. Upgraded based on your advice when I first asked this question. > > Any chance of going to 8.4? If this is what I suspect, you really need > this 8.4 fix: > http://archives.postgresql.org/pgsql-committers/2008-06/msg00227.php > which eliminated the thundering-herd behavior that previous releases > exhibit when the sinval queue overflows. Yes, there is a chance of upgrading to 8.4.4. I just bought a new server and it has 8.4.4 on it, but it won't be onlinefor a while so I can't compare yet. This may motivate me to upgrade the current servers to 8.4.4 too. I was pleasedto see that 8.4 has a new upgrade-in-place feature that means we don't have to dump/restore. That really helps alot. A question about 8.4.4: I've been having problems with bloat. I thought I'd adjusted the FSM parameters correctly basedon advice I got here, but apparently not. 8.4.4 has removed the configurable FSM parameters completely, which is verycool. But ... if I upgrade a bloated database using the upgrade-in-place feature, will 8.4.4 recover the bloat and returnit to the OS, or do I still have to recover the space manually (like vacuum-full/reindex, or cluster, or copy/dropa table)? > Or you could look at using connection pooling so you don't have quite > so many backends ... I always just assumed that lots of backends that would be harmless if each one was doing very little. If I understand yourexplanation, it sounds like that's not entirely true in pre-8.4.4 releases due to the sinval queue problems. Thanks, Craig
В списке pgsql-performance по дате отправления: