On 2012-12-18 12:49, Steve Blinkhorn wrote:
Just to add that commenting out the crontab entries for daily
maintenance worked, in that the system did not go unresponsive last
night. Not a long-term solution, obviously, so any further insights
(e.g., which bits of daily maintenance are likely to stress the
system?) might help save me some hours of toil.
I might have misunderstood something - did you spot a single line that
caused the problem already?
If not, and if you can reproduce the problem by running the /etc/daily
manually, you could (I think) at least narrow it down by disabling
things in /etc/daily.conf and see which one(s) trigger the problem.
Since reboots and waiting for fsck is involved, a binary search might be
a good idea. (Start with everything disabled; then enable the top half,
then the bottom half, then the top half within whichever causes the
behaviour, and so on.)
It would be a fairly painful way to pinpoint the problem, especially if
there is more than one service that tickles whatever it is that is
happening, but it might help in making sense of things.
Sorry if this is basic knowledge and things that you've already tried,
but just in case it might help make things bearable for Christmas...
On Tue, Dec 18, 2012, at 12:55, Johnny Billquist wrote:
The only thing I have experienced is that as the daily job goes through
all the file system searching for old temp files and whatnot, it fills
all the memory with disk cache, [...]
I normally tweak my vm variables violently, to improve my life.
Not sure that others agree with me, but I've found life much more
bearable when I do this. Otherwise my experience is somewhat like yours.
This was a real pain back when I was running 1.6, but that was because
of a bug, wasn't it? I still set the vm.file{min,max} sysctls much
lower than the defaults though.