Date: Sat, 28 Jul 2001 01:28:51 -0500 From: Jim Bryant <kc5vdj@yahoo.com> To: Tabor Kelly <pdxmax@dsl-only.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Collecting System Statistics Programatically Message-ID: <3B625BA3.DC0DFE4E@yahoo.com> References: <1801448262.20010727135401@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Tabor Kelly wrote: > > I have found how to collect limited system statistics with > sysctlbyname(), but I need to know how to do more. In specific I need > to know how much memory is being used, and what percentage of > processor cycles are being used. > > Any help is greatly appreciated, Thank You. > > Tabor Kelly I have always wanted to see some kind of kernel option to allow an HP-UX style metrics interface. IMHO, it should be a kernel option, but the hooks would have to be in every vital kernel function. HP Measureware is quite handy in load and capacity planning. With new SMP machines and HA tools being made available on a wide basis now, a tightly-coupled kernel-level Measureware-like interface could be a good idea whose time has come. As I said, this should either be a module or a compile-time option for the kernel, as it would introduce a small, but near-negligible, performance hit for the duration of a study, so it should be capable of being disabled for generic production use. My sources in HP say it's been used internally by HP to determine where to tune their kernel code with each successive release since the tightly-coupled measureware interface was established, so the idea would also have practical benefit to the core team and other kernel developers for future planning, and making FreeBSD even more efficient than it already is. At the current state of FreeBSD, this could be a good idea for FreeBSD-6.0. A fair assumption that SMP could be in commodity user-oriented gear by the time FreeBSD-6.0 is -RELEASE in at least 50% of the off the shelf products at the time wouldn't be a stretch assumption IMHO. This plus hardware speed improvements would make any performance hits near-negligible. I floated this idea a few years ago, but got burned up in the flames by people mainly using the performance-hit argument. In this day and age, and especially by the time 6.0-RELEASE is available, IMHO, that will be a dead argument against such a metrics interface at the kernel-level. It also opens the door to third-party userland metrics collection and analysis tools, both standalone, and clustering, both freeware and commercial. Anyone who is unfamiliar with the HP Measureware kernel interface should search on Measureware and HP-UX internals documents at hp.com, the interface is integral to the HP kernel, and covers almost any kernel statistic you can think of, because it is so tightly-coupled to the kernel. A userland daemon exists that can allow collecting such metrics over the wire from a cluster of computers, or from a network of standalone computers into a central capacity-planning workstation running a userland collection/analysis tool. Of course, the collection/analysis tool can exist on the same system being measured, but that in itself would introduce a performance hit [being an X app running on the production ox being measured], and thus is not recommended. I think this is an idea whose time has come. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B625BA3.DC0DFE4E>