Re: CPU report in first line of "vmstat 1" is meaningless
:> :> > On a related note I'm not sure if it makes sense to have the same :> > behaviour for the first line when an interval is set as when it is :> > invoked with no interval. : :...also vmstat seems to exist in a few other OSes (linux e.g). maybe they've :fixed it already (or the netbsd/openbsd/dragonflybsd folks or apple?). : :cheers. :alex No, we haven't. I think it is meaningless too, and I can't imagine any script that would try to snarf that line. Another problem is that vmstat output in general is blowing out its column formatting. We have made some changes in DFly... sub-second intervals can be specified, and I think we enforce at least one space between fields so the output doesn't become totally unreadable. But the blowouts still remain. -Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
On Tuesday, October 19, 2010 10:40:56 am Lars Engels wrote: > On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > > > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > > cp_time value essentially won't roll over (at 1 billion increments per > > > > second it will roll over in 500 years; we currently increment 133 times > > > > per > > > > second, I think). If the value can be calculated accurately, it should > > > > be > > > > printed. > > > > > > Well, it won't roll over, but it's still different from all following > > > lines (in that it effectively shows user/system/idle CPU usage since > > > boot on the first line, and a snapshot over the last interval from then > > > on). I think it's still better to avoid printing it in that case. > > > > All of the first line is that way though. To do this "right" you'd need to > > blank out the entire first line. > > > > vm_stat and iostat on OS X have the current FreeBSD behavior (instant first > > line that summarizes all activity since uptime), so I'd be inclined to just > > leave the existing behavior. > > I'd be very happy if all vmstat and iostat would get a command line > switch to suppress the "summary since last reboot" line. > This information may be useful for some cases but in other cases, like > creating performance data for monitoring systems like Icinga / Nagios > one has to remove the first line(s) manually. I would be fine with that, but I wouldn't alter the format of that line by default. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
On Tue, Oct 19, 2010 at 08:54:38AM -0400, John Baldwin wrote: > On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per > > > second, I think). If the value can be calculated accurately, it should be > > > printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since > > boot on the first line, and a snapshot over the last interval from then > > on). I think it's still better to avoid printing it in that case. > > All of the first line is that way though. To do this "right" you'd need to > blank out the entire first line. > > vm_stat and iostat on OS X have the current FreeBSD behavior (instant first > line that summarizes all activity since uptime), so I'd be inclined to just > leave the existing behavior. I'd be very happy if all vmstat and iostat would get a command line switch to suppress the "summary since last reboot" line. This information may be useful for some cases but in other cases, like creating performance data for monitoring systems like Icinga / Nagios one has to remove the first line(s) manually. pgpC5OK9NKDHe.pgp Description: PGP signature
Re: CPU report in first line of "vmstat 1" is meaningless
On Monday, October 18, 2010 3:30:11 pm Ed Maste wrote: > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > cp_time value essentially won't roll over (at 1 billion increments per > > second it will roll over in 500 years; we currently increment 133 times per > > second, I think). If the value can be calculated accurately, it should be > > printed. > > Well, it won't roll over, but it's still different from all following > lines (in that it effectively shows user/system/idle CPU usage since > boot on the first line, and a snapshot over the last interval from then > on). I think it's still better to avoid printing it in that case. All of the first line is that way though. To do this "right" you'd need to blank out the entire first line. vm_stat and iostat on OS X have the current FreeBSD behavior (instant first line that summarizes all activity since uptime), so I'd be inclined to just leave the existing behavior. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
On Mon Oct 18 10, Dan Nelson wrote: > In the last episode (Oct 18), Ed Maste said: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per second, I think). If the value can be calculated accurately, it > > > should be printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since boot > > on the first line, and a snapshot over the last interval from then on). I > > think it's still better to avoid printing it in that case. > > It is documented to do that, though, and could affect scripts that expect to > see average-since-boot info on the first line. iostat does the same, btw. > > > On a related note I'm not sure if it makes sense to have the same > > behaviour for the first line when an interval is set as when it is > > invoked with no interval. ...also vmstat seems to exist in a few other OSes (linux e.g). maybe they've fixed it already (or the netbsd/openbsd/dragonflybsd folks or apple?). cheers. alex > > -- > Dan Nelson > dnel...@allantgroup.com -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
On Mon Oct 18 10, Dan Nelson wrote: > In the last episode (Oct 18), Ed Maste said: > > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > > cp_time value essentially won't roll over (at 1 billion increments per > > > second it will roll over in 500 years; we currently increment 133 times > > > per second, I think). If the value can be calculated accurately, it > > > should be printed. > > > > Well, it won't roll over, but it's still different from all following > > lines (in that it effectively shows user/system/idle CPU usage since boot > > on the first line, and a snapshot over the last interval from then on). I > > think it's still better to avoid printing it in that case. > > It is documented to do that, though, and could affect scripts that expect to > see average-since-boot info on the first line. iostat does the same, btw. > > > On a related note I'm not sure if it makes sense to have the same > > behaviour for the first line when an interval is set as when it is > > invoked with no interval. don't know if you have seen this, but this behavior has been documented in a PR back in 2001: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/30360 cheers. alex > > -- > Dan Nelson > dnel...@allantgroup.com -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
In the last episode (Oct 18), Ed Maste said: > On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > > cp_time value essentially won't roll over (at 1 billion increments per > > second it will roll over in 500 years; we currently increment 133 times > > per second, I think). If the value can be calculated accurately, it > > should be printed. > > Well, it won't roll over, but it's still different from all following > lines (in that it effectively shows user/system/idle CPU usage since boot > on the first line, and a snapshot over the last interval from then on). I > think it's still better to avoid printing it in that case. It is documented to do that, though, and could affect scripts that expect to see average-since-boot info on the first line. iostat does the same, btw. > On a related note I'm not sure if it makes sense to have the same > behaviour for the first line when an interval is set as when it is > invoked with no interval. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
On Mon, Oct 18, 2010 at 01:11:42PM -0500, Dan Nelson wrote: > Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit > cp_time value essentially won't roll over (at 1 billion increments per > second it will roll over in 500 years; we currently increment 133 times per > second, I think). If the value can be calculated accurately, it should be > printed. Well, it won't roll over, but it's still different from all following lines (in that it effectively shows user/system/idle CPU usage since boot on the first line, and a snapshot over the last interval from then on). I think it's still better to avoid printing it in that case. On a related note I'm not sure if it makes sense to have the same behaviour for the first line when an interval is set as when it is invoked with no interval. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CPU report in first line of "vmstat 1" is meaningless
In the last episode (Oct 18), Ed Maste said: > The us/sy/id CPU usage numbers in the first line of vmstat are not useful, > because they're calculated based on kern.cp_times since boot, and not a > delta as are all subsequent lines. If the system has been up long enough > wrapping may come in to play, giving negative results. For example, on > one machine I see: Maybe only blank it out on 32-bit machines? It's a long, and a 64-bit cp_time value essentially won't roll over (at 1 billion increments per second it will roll over in 500 years; we currently increment 133 times per second, I think). If the value can be calculated accurately, it should be printed. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CPU report in first line of "vmstat 1" is meaningless
The us/sy/id CPU usage numbers in the first line of vmstat are not useful,
because they're calculated based on kern.cp_times since boot, and not a
delta as are all subsequent lines. If the system has been up long enough
wrapping may come in to play, giving negative results. For example, on
one machine I see:
$ vmstat 1
procs memory pagedisks faults cpu
r b wavm fre flt re pi po fr sr da0 pa0 in sy cs us sy id
1 0 2 1097M 227M 101 0 0 0 195 45 0 0 483 40 243 -24 -33 157
1 0 2 1102M 222M 1396 0 0 00 0 0 0 159 2170 826 25 2 74
1 0 2 1107M 218M 1124 0 0 00 0 0 0 146 2217 789 24 2 74
Should we wait for one interval before displaying the first line, or
display nothing (or a placeholder like '-')?
Below is a quick patch that illustrates the issue, and implements the
"display nothing" option. With the patch the output looks like:
$ vmstat 1
procs memory page disk faults cpu
r b w avmfre flt re pi pofr sr ad0 in sy cs us sy id
3 0 0 1971M85M 326 0 0 0 334 5 0 457 3674 1495
2 0 0 1971M85M23 0 0 0 0 0 0 301 3634 1209 5 7 88
1 0 0 1971M85M74 0 0 0 0 0 0 510 4655 1619 7 3 90
And the patch:
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 214019)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -658,6 +658,7 @@
int ncpus, maxid;
u_long cpumask;
int rate_adj;
+ int have_prev_cp_times = 0;
uptime = getuptime();
halfuptime = uptime / 2;
@@ -803,10 +804,13 @@
(unsigned long)rate(sum.v_intr - osum.v_intr),
(unsigned long)rate(sum.v_syscall - osum.v_syscall),
(unsigned long)rate(sum.v_swtch - osum.v_swtch));
- if (Pflag)
- pcpustats(ncpus, cpumask, maxid);
- else
- cpustats();
+ if (have_prev_cp_times) {
+ if (Pflag)
+ pcpustats(ncpus, cpumask, maxid);
+ else
+ cpustats();
+ } else
+ have_prev_cp_times = 1;
(void)printf("\n");
(void)fflush(stdout);
if (reps >= 0 && --reps <= 0)
-Ed
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
