[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how to counteract slowdown



On Mon, 12 Nov 2001, Andrew Morton wrote:

[...]

> A fragmented journal would be bad, of course.  It's better to
> create a journal on an empty disk if one possibly can.
> 
> However in this case, I'm theorising that the blockage is on
> checkpoint writeback: ie, the data which has already been
> written into the journal and which is now being written into
> the main fs - we can't recycle the journal space until this data
> has hit disk, and we write it _all_ out.
> 
> Interesting.  Thanks.  We need to start checkpointing earlier,
> non-blockingly.  hmm.

Please.  At the moment, performance on my machine has some notable
hiccups when fetching mail.

I use fetchmail and it takes around 30 seconds to pull down 250 messages
oven the SSH tunnel it's using. So, I see the mail fetching running fine
for five seconds -- then stall as data is written out to disk. ~1.5k
write operations, in fact, stalling the system for ~3/4 seconds.

The fetch then picks up again, happily, until the next five second
burst.


The setup is that mail is fetched and fed to a local Postfix process
that drops it into it's internal queue system, which is on a disk with a
100MB journal and data=journaled.

Fetchmail continues doing this for ~30 seconds, fetching mail from a
remote system and feeding it to Postfix fairly quickly.


Postfix, in the meantime, shuffles the file name around between a few
directories on that first disk, then appends the data to ~/Mailbox. This
is on a second partition, but the same disk, with a 100MB journal and
data=journaled.


The total data fetched is well under 5MB. Even accounting for ten copies
of that, it should *never* have filled the journal more than 50% full --
and the mail fetch has been the *only* read/write activity (other than
inode atime) going on at that stage...


I can't for the life of me see why my system ends up blocking on writes
every five seconds during this process. It strikes me that the data
should all be hitting the journal and, at worst, starting to flush
gently. No blocking of anything, if possible.


It would be *really* nice to see a two or three level flush implemented,
based on the degree to which the journal has filled.

More importantly, it would be good to see the synchronous flush at the 5
second mark (write-back delay in the kjournald thread) stop happening
unless it actually *needs* to be done.

        Daniel

Except, of course, I bet I missed some obvious point that y'all can tell
me about. :

-- 
Life in Lubbock, Texas taught me two things. One is that God loves you and
you're going to burn in hell. The other is that sex is the most awful, dirty
thing on the face of the earth and you should save it for someone you love.
        -- Butch Hancock





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]