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