kapil.thangavelu at canonical.com
Tue Aug 17 01:38:12 UTC 2010
On Tue, 13 Jul 2010 23:15:00 -0400, Cole <coleton at gmail.com> wrote:
> So this may be a little long winded...
> To quickly preface my thoughts I first want to state something pretty
> obvious. In a multi tenant environment ( the current direction we seem
> be headed ) I could care less about some of the tools that are packaged
> sysstat and procps. I don't care about load avg etc for self explanatory
> reasons and presently io reporting (especially in a multi app/multi user
> scenario) is lacking.
> That being said I think tools like atop, systemtap, oprofile are good but
> present 2 problems. They are still tools with competition from closed
> source companies ( BMC to name 1) that will ultimately lead to
> in collected data and they stop short of the challenge The Linux
> has asked the community to tackle with regard to keeping the kernel
> for the next 5-10 years.
> KSLM is focused purely on gathering statistics around the 5 basic
> of compute ( cpu / memory / disk (storage) / time / IO (disk and net) on
> per process basis in a standard way across distros and cpu architectures
> using a consistent thing across all implementations (the kernel itself).
> So to summarize, could kslm be used to solve the same issue described
> yep! Would it be as elegant as atop? Part of it's elegance is that it's
> distro agnostic and if used correctly, could be used to actually do
> intelligent workload management and remediation if conditions (like long
> disk waits) are met.
One issue, is that it appears that is zero public information (as per
google) on KSLM. Could you lend any pointers to code or documentation
about KSLM? I waited and had a look at your linuxcon slides but there's
not much content there.
All measurement tools will face competition from other measurement tools,
be they commercial or opensource. In terms of distro agnostic mechanisms
of capturing those 5 metrics on a per process basis, afaics atop w/ kernel
process accounting patch does indeed provide this minus the notion of
process disk (storage).
> On Tue, Jul 13, 2010 at 2:04 PM, Clint Byrum
> <clint.byrum at canonical.com>wrote:
>> On Jun 30, 2010, at 1:10 PM, Tim Gardner wrote:
>> > You are correct in that I am reluctant to drag in unmaintained crack
>> > into core kernel structures.
>> > I still find 'better task accounting' to be insufficient
>> > What specifically makes for better task accounting? Why is atop better
>> > then other methods? As far as I can tell the current patches still
>> > suffer from the deficiencies mentioned by Andrew Morton in
>> > http://marc.info/?l=linux-kernel&m=120716470803492&w=2
>> > Gimme an example of a problem that atop will help solve for which no
>> > other method will suffice.
>> I just recently was contacted by a friend looking for help on periodic
>> "total site freeze" issues with a web application. Atop revealed some
>> behaving processes where regular top did not, because processes "in disk
>> wait" might be waiting to read/write, and with hundreds of httpd's on
>> machine in disk wait, its painful to try and find out whats going on.
>> such an instant revelation of activity, I really think as systems scale
>> these sorts of tools are really vital.
>> Whether atop as it is now is the way to do this remains to be decided. I
>> recall talking with Cole Crawford at UDS about KSLM which may add
>> capabilities to the kernel but in a more elegant way. I've CC'd Cole to
>> his opinion on this as well.
More information about the ubuntu-server