Messages in this thread | | | From | Ingo Oeser <> | Subject | Re: statfs() / statvfs() syscall ballsup... | Date | Wed, 15 Oct 2003 15:25:40 +0200 |
| |
On Monday 13 October 2003 10:45, Helge Hafting wrote: > Greg Stark wrote: > [...] > > In reality there is no time pressure on the vacuum at all. As long as it > > completes faster than dead records can pile up it's fast enough. The > > transactions on the other hand must complete as fast as possible. > > This seems almost trivial. If the vacuum job runs too much, > overusing disk bandwith - throttle it!
If you are using regular read/write syscalls and not too big chunks --> trivial. If you mmap you database --> harder.
If you would like to tell the kernel, that this should not be treated like a sequential read --> fadvise/madvise.
> This is easier than trying to tell the kernel that the job is > less important, that goes wrong wether the job runs too much > or too little. Let that job sleep a little when its services > aren't needed, or when you need the disk bandwith elsewhere.
Here I agree as this seems like a solution.
The problem is, that you sometimes need low latency for your transactions and then you cannot start throttling a heavy IO process, whose IO is already issued and who is basically just waiting for disk eating its bandwidth.
The questions are: How IO-intensive vacuum? How fast can a throttling free disk bandwidth (and memory)?
Regards
Ingo Oeser
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |