Re: [PERFORM] Background vacuum

2007-05-19 Thread Ron Mayer
Greg Smith wrote: > > Let's break this down into individual parts: Great summary. > 4) Is vacuuming a challenging I/O demand? Quite. > > Add all this up, and that fact that you're satisfied with how nice has > worked successfully for you doesn't have to conflict with an opinion > that it's not

Re: [PERFORM] Background vacuum

2007-05-18 Thread Greg Smith
On Fri, 18 May 2007, Ron Mayer wrote: Anecdotally ;-) I've found renice-ing reports to help Let's break this down into individual parts: 1) Is there enough CPU-intensive activity in some database tasks that they can be usefully be controlled by tools like nice? Sure. 2) Is it so likely th

Re: [PERFORM] Background vacuum

2007-05-18 Thread Ron Mayer
Tom Lane wrote: > Ron Mayer <[EMAIL PROTECTED]> writes: >> Greg Smith wrote: >>> Count me on the side that agrees adjusting the vacuuming parameters is >>> the more straightforward way to cope with this problem. > >> Agreed for vacuum; but it still seems interesting to me that >> across databases

Re: [PERFORM] Background vacuum

2007-05-17 Thread Tom Lane
Ron Mayer <[EMAIL PROTECTED]> writes: > Greg Smith wrote: >> Count me on the side that agrees adjusting the vacuuming parameters is >> the more straightforward way to cope with this problem. > Agreed for vacuum; but it still seems interesting to me that > across databases and workloads high priori

Re: [PERFORM] Background vacuum

2007-05-17 Thread Ron Mayer
Greg Smith wrote: > > Count me on the side that agrees adjusting the vacuuming parameters is > the more straightforward way to cope with this problem. Agreed for vacuum; but it still seems interesting to me that across databases and workloads high priority transactions tended to get through fast

Re: [PERFORM] Background vacuum

2007-05-17 Thread Greg Smith
Ah, glad this came up again 'cause a problem here caused my original reply to bounce. On Thu, 10 May 2007, Ron Mayer wrote: Actually, CPU priorities _are_ an effective way of indirectly scheduling I/O priorities. This paper studied both CPU and lock priorities on a variety of databases includ

Re: [PERFORM] Background vacuum

2007-05-17 Thread Ron Mayer
Andrew Sullivan wrote: > On Thu, May 10, 2007 at 05:10:56PM -0700, Ron Mayer wrote: >> One way is to write astored procedure that sets it's own priority. >> An example is here: >> http://weblog.bignerdranch.com/?p=11 > > Do you have evidence to show this will actually work consistently? The paper

Re: [PERFORM] Background vacuum

2007-05-17 Thread Andrew Sullivan
On Thu, May 10, 2007 at 05:10:56PM -0700, Ron Mayer wrote: > One way is to write astored procedure that sets it's own priority. > An example is here: > http://weblog.bignerdranch.com/?p=11 Do you have evidence to show this will actually work consistently? The problem with doing this is that if you

Re: [PERFORM] Background vacuum

2007-05-10 Thread Ron Mayer
Dan Harris wrote: > Daniel Haensse wrote: >> Has anybody a nice >> solution to change process priority? A shell script, maybe even for java? One way is to write astored procedure that sets it's own priority. An example is here: http://weblog.bignerdranch.com/?p=11 > While this may technically wo

Re: [PERFORM] Background vacuum

2007-05-09 Thread Dan Harris
Daniel Haensse wrote: Dear list, I'm running postgres on a tomcat server. The vacuum is run every hour (cronjob) which leads to a performance drop of the tomcat applications. I played around with renice command and I think it is possible to reduce this effect which a renice. The problem is how c

[PERFORM] Background vacuum

2007-05-09 Thread Daniel Haensse
Dear list, I'm running postgres on a tomcat server. The vacuum is run every hour (cronjob) which leads to a performance drop of the tomcat applications. I played around with renice command and I think it is possible to reduce this effect which a renice. The problem is how can I figure out the PID