[CentOS] Shrinking a volume group

[William L. Maltby]

On Thu, 2006-09-14 at 10:11 -0500, Steve Bergman wrote:
> 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.

What the admin can bring to the game, *if* the developers chose to
implement it, would be a "foreknowledge". When a new system is set up,
admin could tell machine, e.g., lots of print activity, little serial
terminal activity, lots of HTTP, ... time frames, etc. This would "seed"
the heuristics to achieve "optimal" a bit faster (or slower if admin is
in error). Ditto if admin knew a big change was coming.

> 
> 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.

Ditto. I would now regale you with stories about 3B2, 3B20, 3B10, *86
etc. implementations in a large (200 person) development group and other
useless trivia. But that requires a libation or two and we are so far OT
now.

As to "pre-date", that matters not. I'm sure I've forgotten almost
everything from that era but for what I used a lot.

It's the human stuff I remember most. Like screaming my lungs out at an
ANSI committee chairman who did not appreciate my working Thanksgiving
holidays on an EDI application installation on a 3B2 at home while he
ate his turkey. Later learned he messed up his specs to me and was
covering his ass.

>
> I'm thinking about tuning the buffer cache (NBUF).  Let's see, IIRC, the
> <snip>

> 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. ;-)

Not fun for me! I've 2 active brain cells left and I try to use them for
stuff I need *now*. When the DEC 11/70 was replaced by our 3B, I forgot
everything about the Dec except for UNIX related stuff (PWB 6/7,
followed by UNIX SYS III let me adapt easily to UNIX System IV. A lot of
folks are aware there was such a version. This was "native" on the 3B20,
3B10(?) and 3B2 initially).

> 
> 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.

Keep in mind that due to eqpt. cost, most *IX systems of the day were
*not* single user and "terminals" were "dumb", not PCs. So a single
tuning on a "server" might provide benefit for a large number of users
(PCs still too expensive to justify one on each desk). And *that* fact
is what made the expense of tuning worthwhile at the time.

As to "every time someone started...", I know you are being facetious.
The difficulty began as soon as management realized "the system's
running great! I bet we can add <nameyourapp> without any problem". And
they would decide that yesterday was an appropriate time to do it...
without planning, consideration, care for your home life, ...

> <snip>

> 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.

A natural result of "design by committee". You must see that "60" was a
"compromise"?

> <snip>

> ... 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.

Huh? Didn't you listen to anything I said?  ;-)  They are *both* right
for the environment in which they *think* they exist. They have defined
the problem appropriately, for their environment and needs, and see a
solution that addresses that problem! :-)  We'll presume they are not
being myopic here.

For those that are totally interactive, have a restricted set of typical
apps and have $$ for memory, 0% swap may be correct. You can surmise the
other examples I would mention.

> <snip>

> 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) tun-ables.
> 
> Do we kinda agree on that?

Yes.

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

I did not see that. I saw a good discussion, albeit OT, and replied in a
friendly (I hope) vein.

I'll stop here. You can never tell which of the thousands of OT threads
here will be actually deemed such (or when they will be so designated)
and cause severe chastisement by the management.

> <snip sig stuff>

Enjoy!
--
Bill