--pgp-sign-Multipart_Wed_Jul_19_20:35:07_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Wed, 19 Jul 2006 00:10:48 +0200,
Johnny Billquist wrote:
>=20
> No, I'm not short on RAM. And no, more ram don't solve every problem.
> A typical case of this is when much of a large file system is run=20
> through once. This will fill up the caches with lots of data that will=20
> not be referenced again, over and over again pushing out executable=20
> programs from memory, which will be referenced again.

If you have enough memory to accomodate all the requirements specified
in your VM settings then you can run through the biggest possible full
filesystem and never push out any _active_ pages of anonymous or exec
memory.  And you don't have to avoid having any buffer cache at the same
time either.

Running once through file data that'll never be referenced again isn't
something that default OS tuning is likely ever going to be set for
either.  The buffer cache isn't just a whim -- it can have an enormous
benefit for many "normal" load profiles.


> And my systems are not starved for I/O throughput, the problem is (was)=20
> that programs got way too little memory, and caches way too much.

Yeah, but you can't expect to run several large or largish programs at
the same time as you read through many files on a small-memory machine
and still get the most optimum performance imaginable, especially if you
don't tune it so that it has some better idea of what you think has the
highest priority.


If your goal here is to try to influence the best default settings for
the vm.* sysctls, then perhaps you might try to use a few less drastic
values and see how your machine performs under the same loads.

For example here are the settings and comments I have in
/etc/sysctl.conf on a variety of servers and workstations.  None of them
are starved for memory, and some have more than enough, but these
parameters seem to give good overall performance for "normal" workloads:

Note that I've under-committed the minimums but over-committed the
maxiums -- this should give some leeway to the various algorithms that
try to do the right thing for the very immediate needs of the system.

Perhaps the biggest problem with the current defaults is that they can
lead to large swings in priority which can maybe lead to sluggish
behaviour, and that's not going to mix well with interactive use.

# 	VM pager tuning parameters
#
# Questions:  Does the pager eventually always free inactive pages
# above the vm.*max limits?  Is this worse for exec and file pages
# than it is for anon pages?  Does it even matter if inactive anon
# pages are preserved for very long?
#
# See http://www.selonen.org/arto/netbsd/vm_tune.html
# and of course http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz

# the minimum percentage of memory always (made) available for anonymous pa=
ges
#
# The default is 10, which is probably way too low...
#
vm.anonmin=3D40

# the maximum percentage of memory that will be reclaimed from others for a=
nonymous pages
#
# The default is 80, which seems just about right, but then again it's
# unlikely that the majority of inactive anonymous pages will ever be
# reactivated so maybe this should be lowered?
#
#vm.anonmax=3D80

# the minimum percentage of memory always (made) available for text pages
#
# The default is 5, which is probably somewhat too low...
#
vm.execmin=3D40

# the maximum percentage of memory that will be reclaimed from others for t=
ext pages
#=20
# The default is 30, which seems way too low, esp. for big programs on
# small memory systems...
#
vm.execmax=3D50

# the minimum percentage of memory always (made) available for the file dat=
a cache
#
# The default is 10, which is too high, even for most large-memory
# systems...
#
vm.filemin=3D5

# the maximum percentage of memory that will be reclaimed from others for f=
ile data cache
#
# The default is 50, which may be too high for small-memory systems
# but may be about right for large-memory systems...
#
#vm.filemax=3D50


--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_Jul_19_20:35:07_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: fNf9JPtqcSb+CIWl7Z2p2ONZkn8zdqU0

iQA/AwUBRL7PymJ7XxTCWceFEQJ1eACg9hf22etihPmmTfQoboJMiyYw2fwAn3wQ
pE84/7rt+9xQcw/OAdGbMdgu
=oazC
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Jul_19_20:35:07_2006-1--