Comment on Monitor General Server / Desktop system health in console on Linux and FreeBSD by Mark Seger.
If you like full screen utilities like top, just remember you can use –home with collectl and get the same effect with any command you choose, not just disk, cpu and memory. Repeat after me, if you can think of it, collectl probably does it. 😉
I don’t use curses either. real programmers talk to the terminal directly using the appropriate escape sequences. 😉
as a bonus, try this command: “collectl –top -scdn”
-mark
Recent Comments by Mark Seger
How to find out which processes are causing a hard disk I/O overhead in GNU/Linux
The good news is it is now currently in the debian release process. The other good news, which may not be obvious, is it you just grab and untar the src.gz tarball, cd to the directory and type ./INSTALL, it will figure out it’s debian and do the right things. In fact, that’s the way the debian install package is built. 😉
-mark
How to find out which processes are causing a hard disk I/O overhead in GNU/Linux
don’t get too hung up on having a kit that has been supplied as part of a distro – lots of great stuff is not part of any distro, like collectl-utils (and collectl before that). Just unpack the tarball into /tmp and run INSTALL. very simple script and if you’re nervous, just manually run the few copy commands it runs.
-mark
How to find out which processes are causing a hard disk I/O overhead in GNU/Linux
Glad you’re finding collectl useful – have you tried the collectl-utils yet? Adds plotting and cluster-wide ‘top’ functionality for anything collectl can collect. a few comments:
– collect is definitely in active development and current plans are to release a new version next week, the most noticeable addition being numa stats
-it is currently included in fedora and suse and is being added to the next release of debian. but you can also install the rpm on any system that support rpm, OR just go with the source tarball and run INSTALL.
– as for performance I can almost guarantee sar and systat are faster since they’re written in C and collectl is written in perl. My original plan was to write collectl in perl as a prototype but it’s so efficient that I don’t see any benefits in giving up the ease at which I can add additional capabilities to move to C or any other language
As I’ve said before sar and iostat (and many others) are fine tools but I find them limiting in a variety ways including inconsistencies in their data reporting with each other as well as completeness in what they report – I want a single tool so ALL data can be recorded within microseconds of each other so one can observe how the system as a whole is behaving, especially in response to a problem.
Another important thing is I’m on a mission to educate people to the harm in running sar at its default monitoring interval of 10 minutes. This is such a coarse measure as to be almost meaningless for diagnosing all but the most basic problems. Consider a 1 minute network spike on a moderately loaded network – you’ll never see it! Sar users: please lower your monitoring frequencies. A minute is far better than 10 but of course I’m a big advocate of collectl’s 10 second interval and there are a number of collectl users who choose even 5 or 1 second sampling rates. The more you collect the more you will see.
-mark
