> > Filesystem is ext3 with one big / partition (that's a mistake
> > we won't repeat, but too late now). This should be mounted
> > with data=journal given the kernel command line above, though
> > it's a bit hard to tell from the dmesg log:
> >
>
> It's possible tht the journal keeps on filling. When that happens,
> everything has to wait for writeback into the main filesystem.
> Completion of that writeback frees up journal space and then everything
> can unblock.
>
> Suggest you try data=ordered.
We have a 192M journal, and from the dmesg log it's saying that it's got a 5
second flush interval, so I can't imagine that the journal is filling, but
we'll try it and see I guess.
What I don't understand is why the spike is so sudden, and decays so slowly.
It's Friday night now, so the load is fairly low. I setup a loop to dump
uptime information every 10 seconds and attached the result below. It's
running smoothly, then 'bam', it's hit with something big, which then slowly
decays off.
A few extra things:
1. It happens every couple of minutes or so, but not exactly on any time, so
it's not a cron job or anything
2. Viewing 'top', there are no extra processes obviously running when it
happens
Rob
-
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/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:42 EST