[CentOS] Shrinking a volume group

[Steve Bergman]

On Thu, 2006-09-14 at 09:58 -0400, William L. Maltby wrote:
> And so you believe that it will be as good as, or better, at
> predicting
> that some external "random" event will occur that needs "this"
> particular piece of cache? Or buffer? Theoretically, a heuristic
> algorithm could be developed that does better. But that ultimately
> comes
> down to just redefining the problem to be solvable with a changed set
> of
> parameters. The same thing a "human" tuner would do. But it would do
> it
> "cheaper" and so biz will be happy.
> 

I think that the above paragraph shows where we really agree.  This is
like chess.  The machine has the ability to gather the relevant info and
come to a decision a hundred time a second.  No admin could ever be so
dynamic.  Humans are good at having a "feel" for the game.  An intuition
about the right thing to do.  But the machine has gotten good enough
that it can beat most human chess players.  It can even beat the Grand
Masters sometimes.

Is this because (human) Grand Masters are less competent today?

No.  It is because the machine has gotten faster and smarter.

Your Unix experience predates mine.  I didn't start until 1987.  But
I've much experience with the old 3B2's, and Unix/386 3.1+.  And Xenix
(LOL) and SCO Unix, Unixware and the other old school RTFM Unixes.

I'm thinking about tuning the buffer cache (NBUF).  Let's see, IIRC, the
general rule of thumb was to start at about 10%-25% of memory.  Each
NBUF took up 1k, I believe.  Of course, then you had to set the buffer
headers (NHBUF). It was recommended to start those out at about 1/4 of
NBUF.  But they had to be (were recommended to be?) a power of 2.  Each
NHBUF was, I believe, 64 bytes.

These values were set at kernel link time and never changed.

This is all from memory.  I didn't Google or Wikipedia for any of it
since it's so much fun to try to dredge up obsolete and useless info out
of my own brain. ;-)

But that's really my point.  This info, interesting as it was at the
time, *is* quite useless and obsolete.

I'm looking at my desktop system right now.  It has about 70% of
physical memory devoted to disk buffers and cache.  I start OpenOffice
and that number decreases.

I would *never* have set NHBUF that high!  And rightly so.  Unixes back
then were so stupid in comparison to today's Linux that it would have
been suicide.  Because as soon as someone started
OpenOffice^WWordPerfect, the system would have thrashed to a halt.  And
I *couldn't retune and relink the kernel every time someone started or
stopped an app.

Certainly, a combination of the machine's speed at doing things the
"mechanical" way, and human knowledge and intuition would be optimal.

But if Linux has fewer control knobs, I see that as a good thing.
They're not as much needed.  And in fact, if they existed, would do more
harm than good.

Every admin "knows" what the "best" policies are.  No two agree, of
course, but that doesn't stop them from "knowing" it.

OK.  Maybe it depends on your "workload".  But I see plenty of people
telling each other to set swappiness to 0 or 10 or 90 or 100 to reduce
latency.  No one ever seems to recommend leaving it at 60.  60 is just
bad, I guess.

The only hard data that I have ever seen anyone present, indicated that
60 was close, but a bit high for their "workload".

Just read over that thread from April 2004 that I linked.  You can see
that there is more going on than just different "workloads".  There are
fundamental differences in the way even kernel devs think about swap.
These can be roughly divided into the "swap is good" and "swap is bad"
camps.  They can't both be right.

Anyway, Linux does have a few knobs. (No pun intended.) ;-)

For an interesting look at what the RHEL4 (two year old kernel) has,
see:

http://people.redhat.com/nhorman/papers/rhel4_vm.pdf#search=%22vm%
20rhel4%20pdf%22

So, in conclusion, I will say that a *truly* well studied admin, armed
with today's tools, including the kernel's automatic mechanisms, can do
better than the automatic mechanisms alone.  The average admin is likely
to make things worse.

Both will probably do better than the smartest admin was able to do with
old school Unix and its panoply of (rather static) tunables.

Do we kinda agree on that?

Oh, and my original post might have come across as a bit more
confrontational than intended.  If it did, I apologize. Confrontational
is counterproductive. ;-)