On Mon, 2006-06-05 at 16:17 -0500, Les Mikesell wrote: > On Mon, 2006-06-05 at 17:00 -0400, William L. Maltby wrote: > > I can't resist. Read the thread that was pointed to on lkml. ROTFLMAO. > > > > *Real* UNIX addressed these problems long ago. I guess the "Gurus" > > suffer from NIH (Not Invented Here) syndrome. > > > > Given a "general purpose" system, tunability is a must. UNIX, as > > delivered by USL in such examples as 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 your mix of programs > change or you add memory except in some very unusual circumstances > like a server that does a single job forever. In the general > case 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. For many business applications, there is a list of performance requirements that can be prioritized. Priorities can vary, even within a node, based on many things, including time of day. An admin with access to the means can help ensure that his installation is meeting the goals necessary for the business. 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. -- 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/1ba66120/attachment-0004.sig>