[CentOS] Swap: typical rehash. Why?

[William L. Maltby]

On Mon, 2006-06-05 at 18:40 -0500, Les Mikesell wrote:
> On Mon, 2006-06-05 at 17:37 -0400, William L. Maltby wrote:
> > ><snip>

> > > > <snip> ... Sys V, had tunables that let admins
> > > > tune to their needs. A single "swappiness" value is woefully inadequate.
> > > 
> > > Actually, having these computed dynamically is much better than
> > > having to manually tune them every time <snip>

> > > ... consider whether you'd rather hire an expert admin to
> > > keep your system tuned or buy an extra gig of ram and let the
> > > OS figure out how to use it.
> > 
> > I agree, sort of. The problem occurs in that the OS is only somewhat
> > heuristic. It learns, but only a small amount. The admin can run SAR
> > reports and use other tools that profile activities and he can use that
> > information to "pre-bias" the VM so that it better achieves *long-term*
> > performance and responsiveness goals and is less sensitive to "spikes"
> > in one factor or another.
> 
> If you remember those tunables, you might also remember that there was
> a whole fairly large (and boring) book that told an administrator how
> to interpret various permutations of SAR reports and which way to adjust
> the tunable values.  Even when Linux had more hard-coded tunables I was
> never able to find any equivalent reference to use them correctly.

Amen to that. When several flavors of real UNIX were being aggressively
marketed by several corporations, when "craftsmanship" and engineering
were somewhat important in keeping your job, when marketing had to offer
"The Complete Package" (TM) in order to woo customers from a competitor,
corporations saw value in investing in good documentation. Plus, your
performance evaluation as an engineer might depend on producing
documents that your PHB could appreciate and that helped to sell the
product. Development was "structured" (in *some* fashion, yes it
*really* was!) and there was peer pressure to "Do a Good Job". Complete
opposite of what seems to be predominate today. I *think* - no way to
tell with my limited view of the virtual world. From what I see, it
seems to be "throw the s.*t out there and fix the reported bugs. Later".

A side-effect of labor becoming more and more expensive and hardware
becoming cheaper and "free software" and "open source" reducing the
returns to business on proprietary product. Now add the fact that
business can *cheaply* put something out and have it "maintained" for
free and they rake the profits...

> 
> > For many business applications, there is a list of performance
> > requirements that can be prioritized. <snip>

> > When the best of the code is combined with the best of an admin's effort
> > and data analysis, a good outcome is likely. Code only or admin with
> > tools/means both produce less optimal results.
> 
> Yes, but if you can define the solution, the computer could probably
> implement it better and certainly faster by itself.  I think these days
> the developers would rather write the code to do it instead of the
> documentation to tell you what needs to be done.

That is so true. None of us (myself, as a long-time developer, included)
enjoyed the documentation process. It's like washing the dishes after
eating a fine meal. Just no interest in that part of the evening.

The trouble with the real UNIX params, aside from the problem of
learning curve you mention, was that the parameters were the
instantiation (in effect) of the *results* of the calculations that the
admin must perform and the programmer had to envision in the first
place. Since the programmer had envisioned what data had to be processed
for what processing scenarios, an ideal solution would have been to have
a data entry sheet that accepted various expected load parameters, time
frames, performance objectives, ... and would have generated the set of
appropriate tunables, which is what you suggest.

The often overlooked point in these retrospectives is that hardware was
much less powerful (and still expensive) when all this was developed (my
1st UNIX PC, a 186 IIRC, with 64K ram, 5MB HD, 40ms seek?, 12" mono
monitor, nada for graphics, ... like that about $4,000). And I
specifically recall a PC with DOS only advertised in 1985 PC Tech
Journal with a "huge fast 10MB HD 2 5.25" FDs, only $10,995. With a
12MHz 286 IIRC. Sold like hotcakes.

The point of that is there was good reason the developers did not
generate the software to automatically determine the correct parameters.
Too labor intensive and too hardware/cost intensive to implement.
Programmers weren't a dime-a-dozen back then and time constraints also
often limited what could be provided in a given release cycle.

Now, post a request on the web somewhere and there is already free
software from someone or someone will develop it for you for free if
you're patient enough.

The documentation will still suck (if you want the truth, read the code)
and a substantial portion of the user community will still be
dissatisfied.

> 
-- 
Bill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.centos.org/pipermail/centos/attachments/20060605/a14431f4/attachment.sig>