by Kevin Mile » Tue, 19 Jun 2001 22:52:08
i.e.
01:00:00 <<State change>>
....and so on.
On another machine, this works fine and displays correct output. Anyone know
why this
is occuring??
Cheers
Kev
by Tony Walto » Tue, 19 Jun 2001 23:13:56
> When I run (as root) sar -d on a Solaris 2.6 machine I get reports with the
> time
> and <<State change>>
> i.e.
> 01:00:00 <<State change>>
> ....and so on.
> On another machine, this works fine and displays correct output. Anyone know
> why this
> is occuring??
During execution of this kernel status command, the "state"
of the kernel can change. An example would be CPUs going
online or offline. vmstat will report this as <<State
change>>.
(Don't look for it on the manpages for 2.6 as it's not documented there
:-( )
Solaris 2.6 is a bit over-keen on reporting it, however - something as
simple as mounting or unmounting an NFS filesystem will trigger the
message. There are patches which reduce the frequency with which the
message is presented; 106818 (Solaris 2.6/SPARC) and 106819 (Solaris
2.6/Intel). You might also be interested in patches 106651 (SPARC) or
106652 (Intel) and 106655 (SPARC)/106656 (Intel) which apply a similar
fix to rstatd and iostat/mpstat/vmstat respectively.
--
Tony Walton
1. sar problem: updates timestamp, but no sar data
Greetings folks,
I'm trying to figure out a problem that happened to me twice
yesterday. I've done extensive searching and haven't found any
explanation for this behaviour. So, here's the scenario:
I renamed and readdressed two servers, say Box1 and Box2. They have
no real link to one another, save for the fact that they perform
similar functions. Prior to the rename/readdress each of the machines
sar was running fine, reporting data at the expected intervals (sa1
was being run from cron at 5 min intervals). Once the
rename/readdress took place, and the host was booted (just for my own
sanity), I found that while sar would run, and the timestamp on
/var/adm/sa/sa0x would be updated, when running sar -f
/var/adm/sa/sa0x by hand showed that the actual sar data from sa1
wasn't there.
The only solution I could come up with was to move the old datafile
aside and touch (and chmod/chown) an new one. That solved the problem
in that the file was once again actually being written to, however,
that doesn't explain the strange behaviour when trying to write to the
original file. Oh, another note, even when running sa1 by hand, the
file still didn't get written to (either running it as root or as
sys).
Any ideas? The hosts are both SunFire V440's running Sol9, with
/usr/lib/sa/sa1 running at 5 min intervals from the sys crontab.
TIA,
Patrick
2. Multi-port network adapters
4. 2.5.69/ipsec assertion failed
5. sar problem
8. UU.net and rDNS Was: UUNET WorldCom Files Suit Against TCPS
9. Sar problem
10. SAR problem on SCO ODT 3.0
12. sar problem
13. sar problem after performance optimization