Kevin Martin wrote:
<snip>
I read that [3] article and the first two things I noticed were the
reference to "small RAM" which in the days of $11/GB RAM is rare, and
that the author didn't touch the "dirty" tuning parameters, which are
better suited to controlling the behavior of i/o buffers. He didn't
mention tuning read ahead to speed reading of application off the
disk (which limits response even if lots of memory is free). In short
the article is based on one trick, not a balanced approach to getting
both responsive performance and good i/o performance.
I regularly handle images 4x the size of memory, and in 33 days uptime
have written a total of 109MB (from iostat) to swap. A balanced tune
is far nicer than cranking swappiness as low as it will go and keeping
crap in memory which is not needed (left over initialization code,
error messages you never see, etc).
[1]
http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that
[2]
http://apcmag.com/interview_with_con_kolivas_part_1_computing_is_boring.htm
[3] http://apcmag.com/why_i_quit_kernel_developer_con_kolivas.htm
Bill,
You don't mention what types of tuning you've done to enforce a
"balanced approach". Any suggestions are greatly appreciated!
Actually I did, there are some "dirty" parameters right where the swappiness
lives, in /proc/sys/vm and making dirty_expire smaller pushes large writes out
faster. You can also adjust the dirty*ratio values to speed cleansing. The
details are in the "Documentation" directory of the kernel source (and elsewhere
I guess, never looked).
using the "blockdev --setra" option to use a larger readahead will speed reads
from the disk and bring programs in faster. Note that it also uses more memory,
play with care on a small memory machine. This can take 30% off of boot time on
some laptops with slow disk and GB+ ram (most recent laptops, in other words).
Try powers of two starting at 4096 or so until it stops feeling better.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
