Ext3 users - Nov 2002 - /proc/sys/vm/bdflush

I'm lacking some understanding of how to tune / when to tune
/proc/sys/vm/bdflush

Where can I read up on this?

Our current problem: Load is low, but ever so often the system decides
to do some serious disk I/O which causes all processes to wait for
disk I/O -- load explodes (rises linear up into the 20-30ies) just to
fall linearly (spelling?) right after that.

We think there might be some serious buffer flushing going on, but we
cannot put our finger on it.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
Why you can't find your system administrators:
He's out getting a caffine fix. -- John Wanger jwagner@mental.mitre.org

On Thu, 21 Nov 2002 11:15:13 +0100, "Ralf Hildebrandt"
<Ralf.Hildebrandt@charite.de> said:
> Our current problem: Load is low, but ever so often the system decides
> to do some serious disk I/O which causes all processes to wait for
> disk I/O -- load explodes (rises linear up into the 20-30ies) just to
> fall linearly (spelling?) right after that.
> 
Are you using Cyrus? If so, what is your prefork set to in imapd.conf?

We saw what you're seeing, and tracked it down to Cyrus' scheduled event
handling in large prefork pools.

These are my current settings for bdflush:

40 10 0 0 60 512 60 0 0

according to the advice at the following URL:

http://www-106.ibm.com/developerworks/linux/library/l-fs8/

The article recommends a 300 where the 512 is above, but looking at the
kernel source it seems the Red Hat kernel limits the low end of this
parameter to be 512.

As the article states "it's slightly less efficient to do things this
way since the kernel will have fewer opportunities to combine writes,"
but with the above parameters I have good interactive performance from a
data=ordered ext3 RAID volume with 400 users and load averages of 10+ on
a quad Xeon 1.4GHz with 8GB RAM.

I have a question as well - according to tests performed for the article
above, "ext3's data=journal mode is incredibly well-suited to
situations
where data needs to be read from and written to disk at the same time."
This is the situation that exists on my box.  

My question is: has anyone had any real-world experience to backup the
claims of the above statement?  I would love to get better performance,
AND have better data integrity, but that seems to good to be true :)

Thanks,
Andy.


-----Original Message-----
From: Ralf Hildebrandt [mailto:Ralf.Hildebrandt@charite.de] 
Sent: Thursday, November 21, 2002 6:00 AM
To: Ext3 Users
Cc: Udo Wolter
Subject: Re: /proc/sys/vm/bdflush


* Marc-Christian Petersen <m.c.p@gmx.net>:
> > Linux postamt1.charite.de 2.4.19-ac4 #1 Mon Aug 19 14:35:20 CEST
2002 i686
> There is your problem. 2.4.19 and even latest 2.4.20 has those kind of
> behaviour in some situations. I had the same experience. Read the
thread 
> between Andrea and me some days ago.
> 
> Someone wrote you can use:
> 
> elvtune -r 2048 -w 131072 /dev/$yourdevice
> echo "90 500 0 0 600000 600000 95 20 0" >/proc/sys/vm/bdflush
> 
> and with those settings the "freeze" behaviour is gone but I
cannot
confirm 
> that. 2.4.19|2.4.20 has those problems too even with those settings,
but not 
> as worst as without it.
We shall try that. Right now I'm running 2.4.20-rc2, but still have
the occasional lockup.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)
Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450
570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450
570-916



_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://listman.redhat.com/mailman/listinfo/ext3-users