[PATCH] add nmeter applet
Denis Vlasenko
vda at ilport.com.ua
Sat Feb 11 11:53:56 UTC 2006
On Friday 10 February 2006 20:10, Rob Landley wrote:
> > I am submitting a new applet for the review.
> >
> > # size busybox.orig busybox.nmeter
> > text data bss dec hex filename
> > 973258 12184 198804 1184246 1211f6 busybox.orig
> > 979530 12408 202964 1194902 123b96 busybox.nmeter
>
> Having to do math to parse this is kinda distracting. Could you give us
> either the size of "allnoconfig" plus this app, or the size of the .o file?
# size nmeter.o
text data bss dec hex filename
5555 196 4132 9883 269b nmeter.o
> > # ./busybox.nmeter nmeter --help
> > BusyBox v1.1.1-pre0 (2006.02.10-09:12+0000) multi-call binary
> >
> > Usage: nmeter c[N] nIFACE m[f/t] s f i[NN] x p[f/n] b t[N] d[N] h[N] lLABEL
> > LLABEL r
>
> Um, ick.
Actually, it's more like
nmeter [c[N]] [nIFACE] [m[f/t]] [s] [f] [i[NN]] [x] [p[f/n]] [b] [t[N]] [d[N]] [h[N]] [r]
and after any option you may have [l<LABEL>|L<LABEL>],
but such help line would be far too ugly. Your suggestion?
> > Nmeter allows you to monitor your system in real time
>
> So does top.
But in completely different way. top scans entire process tree
in /proc, nmeter just reads a few /proc files. I specifically
avoided stats which are expensive to collect. Even on very
old machines nmeter's own CPU usage is tiny.
> > Options:
> > c[N] monitor CPU. N - bar size, default 10
> > (legend: S:system U:user N:niced D:iowait I:irq i:softirq)
> > nIFACE monitor network interface IFACE
> > m[f/t] monitor allocated/free/total memory
> > s monitor allocated swap
> > f monitor number of used filedescriptors
> > i[NN] monitor total/specific IRQ rate
> > x monitor context switch rate
> > p[f/n] monitor forks/# of processes
> > b monitor block io
> > t[N] show time (with N decimal points)
> > d[N] milliseconds between updates. Default 1000
> > h[N] print headers above numbers (each N lines, default once)
>
> That's kinda silly.
What exactly is silly?
> > lLABEL specify label for previous item
> > LLABEL same, but label will be printed without surrounding blanks
> > r print <cr> instead of <lf> at EOL
>
> That's extremely silly. You might want to look at the man page for strptime.
I do not understand your comment about strptime.
l and L are used to override legend used for a measurement.
# nmeter t c b l"block i/o" nif l"network i/o"
13:08:17 cpu [UU........] block i/o 0 0 network i/o 398 0
13:08:18 cpu [..........] block i/o 0 80k network i/o 274 0
13:08:19 cpu [SUU.......] block i/o 0 60k network i/o 355k 354k
13:08:20 cpu [SUUUUUU...] block i/o 0 0 network i/o 814k 813k
13:08:21 cpu [UUUi......] block i/o 0 0 network i/o 239k 239k
13:08:22 cpu [..........] block i/o 0 0 network i/o 377 0
Useful if one tries to cram many stats into 80-column line without linewrap:
# nmeter t c l i li x lx pn lp p L m lm s ls b lb nif ln
13:21:53 [..........] i 174 x 148 p 163 0 m110M s 0 b 0 0 n 675 0
13:21:54 [..........] i 270 x 231 p 163 0 m110M s 0 b 0 108k n 432 0
13:21:55 [..........] i 254 x 219 p 163 1 m110M s 0 b 0 0 n 338 0
13:21:56 [..........] i 254 x 276 p 163 0 m110M s 0 b 0 0 n 278 0
[ 1 2 3 4 5 6 7 ]
[123456789012345678901234567890123456789012345678901234567890123456789012345678]
I have nmeter output running on my servers on one of their
virtual terminals, helps to quickly guess what kind of load
makes them slow (network? disk? CPU bound process(es)? runaway forking?).
> > # ./busybox.nmeter nmeter
> > 12:46:13 cpu [U.........] mem 153M swp 24M proc 183 fork 1 bio 0
> > 0 12:46:14 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio 0
> > 0 12:46:15 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio 0
> > 148k 12:46:16 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio
> > 0 0 12:46:17 cpu [..........] mem 153M swp 24M proc 183 fork 1 bio
> > 0 0 12:46:18 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio
> > 0 0 ...
>
> That's an abbreviated top, yet this shares no code with our current top
> implementation.
Because as I explained above, there is not much to share.
top does not measure fork rate, network i/o rate or block i/o rate.
nmeter does not scan /proc/NN directories.
> More to the point, from a command line perspective this should just be some
> kind of "terse" option to top.
>
> > Please comment.
>
> Neat idea, but this implementation should not be merged.
>
> Random example: read_decimal sample() is a one line function that's used in
> exactly one place. Why the heck is it a function at all? That function is a
> call to STR2SAMPLE() which is literally just a #define for strtoull...
> That's just wrong, if you want strtoull() then just use strotoull(). The
I can't drop read_decimal_sample(). I need to pass a pointer to function
with correct prototype.
static inline sample_t read_decimal_sample(const char *p)
{
return STR2SAMPLE(p, NULL, 10);
}
static int rdval(const char* p, const char* key, sample_t *vec, ...)
{
...
result = vrdval(p, key, read_decimal_sample, vec, arg_ptr);
^^^^^^^^^^^^^^^^^^^
OTOH I will do STR2SAMPLE -> strtoull cleanup.
> fact there's another #define for STR2SAMPLE() commented out a couple lines
> above the active #define is just extra untidyness: why is there commented out
> code still in the patch?)
Updated patch is attached.
> I get the feeling that a cleaning pass could chop this implementation down to
> about half its current size,
??
> but that doing so would be the wrong approach
> because we've already got a "top" and I really don't want two parallel
> implementations of the same functionality that don't share any code.
>
> This isn't to say that our current top is the best possible implementation,
> but I'd start by cleaning up the current top and adding one-line output
> functionality to that instead. If said cleanup winds up replacing the
> current top code, fine, as long as the end result can do what the current top
> does.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nmeter2.patch
Type: text/x-diff
Size: 24666 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060211/60133cca/attachment.bin
More information about the busybox
mailing list