All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Knoblauch <knobi@knobisoft.de>
To: linux-kernel@vger.kernel.org
Cc: spam trap <spamtrap@knobisoft.de>
Subject: Re: Understanding I/O behaviour
Date: Fri, 6 Jul 2007 04:03:41 -0700 (PDT)	[thread overview]
Message-ID: <543242.2447.qm@web32607.mail.mud.yahoo.com> (raw)

Martin Knoblauch wrote:
>--- Robert Hancock <hancockr@xxxxxxx> wrote:
>
>>
>> Try playing with reducing /proc/sys/vm/dirty_ratio and see how that
>> helps. This workload will fill up memory with dirty data very
>> quickly,
>> and it seems like system responsiveness often goes down the toilet
>> when
>> this happens and the system is going crazy trying to write it all
>> out.
>>
>
>Definitely the "going crazy" part is the worst problem I see with 2.6
>based kernels (late 2.4 was really better in this corner case).
>
>I am just now playing with dirty_ratio. Anybody knows what the lower
>limit is? "0" seems acceptabel, but does it actually imply "write out
>immediatelly"?
>
>Another problem, the VM parameters are not really well documented in
>their behaviour and interdependence.

 Lowering dirty_ration just leads to more imbalanced write-speed for
the three dd's. Even when lowering the number to 0, the hich load
stays.

 Now, on another experiment I mounted the FS with "sync". And now the
load stays below/around 3. No more "pdflush" daemons going wild. And
the responsiveness is good, with no drops.

 My question is now: is there a parameter that one can use to force
immediate writeout for every process. This may hurt overall performance
of the system, but might really help my situation. Setting dirty_ratio
to 0 does not seem to do it.

Cheers
Martin

------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de

             reply	other threads:[~2007-07-06 11:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-06 11:03 Martin Knoblauch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-06 14:25 Understanding I/O behaviour Daniel J Blueman
2007-07-06 15:17 ` Martin Knoblauch
2007-07-06 15:44   ` Daniel J Blueman
2007-07-06 12:44 Martin Knoblauch
2007-07-06 10:18 Martin Knoblauch
     [not found] <fa.gAvf+r9fiPwNwNVqahYy5u1/Is0@ifi.uio.no>
2007-07-05 23:47 ` Robert Hancock
2007-07-05 23:53   ` Jesper Juhl
2007-07-06  7:54     ` Martin Knoblauch
2007-07-06 10:15       ` Brice Figureau
2007-07-06 10:11   ` Martin Knoblauch
2007-07-07 13:23     ` Leroy van Logchem
2007-07-05 15:40 Martin Knoblauch
2007-07-05 18:15 ` Andrew Lyon
2007-07-05 20:22 ` Jesper Juhl
2007-07-08 21:28   ` Jesper Juhl
2007-07-09  8:47     ` Martin Knoblauch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543242.2447.qm@web32607.mail.mud.yahoo.com \
    --to=knobi@knobisoft.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spamtrap@knobisoft.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.