pus can beat a T5120
in throughput as well, as the T5120 is a pretty old box now).
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
pufs project?
Is it still being worked on, dormant, scrapped, or awaiting fresh blood?
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
ss be to increase the stability of a given
> kstat? I suspect some sort of ARC review, but then this gets outside
> of my realm of experience. I suspect a few emails to opensolaris-arc
> or such might prove useful, though I'm not sure if now is the
> appropriate ti
read a
do
line=`echo ${line} + 1 | bc`
done
takes
real8.855
user 1.440
sys 6.254
while doing it this way:
while read a
do
line=$(($line+1))
done
takes
real0.062
user0.054
sys 0.006
as you can see, the difference is substantial.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
if you shove the stability data into the ks_resv field, then you don't
need to change any interfaces, or add any new ones. You just get the data
coming back for free.
(Setting it is a bit different, you need to add something there. But
for reads you
can just let interested c
e/name,
just conventions
that kstat providers are free to break.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
l) it might be easier to simply use
the kstat or its KID as the argument to identify a kstat uniquely.
Another possible design would be to do away with the separate call,
and simply appropriate the (currently unused)ks_resv field in the kstat
structure to hold the stability data.
> ??: How s
ake work anyway; and there's major
investment required to fill in the gaps (or implement multiple solutions).
Despite knowing that it's wrong, there's a distinct possibility that
we roll our own again.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
of vmstat), and add
> what is missing - which means adding kstats to the kernel.
Isn't that what the project says: "exposes well known Solaris performance
metrics via SNMP". It's deliberately open. The mention of mpstat and
whatever is just an example - I would actual
x27;s
doing here as 'make available via snmp useful information that you would
otherwise have to log in to a server and type a bunch of commands to get'.
It's not 'emulate every bug in the existing tools', and certainly isn't limited
to only displaying what the
Or using an older version that works. The one integrated reports itself as
top: version 3.8beta1
I've never seen a memory leak in any of the other versions I've used,
which covers
20 years.
--
-Peter Tribble
http://www.petertribble.co.uk/ -
s some sort of bug
That would be bug 6777385. The current top (the latest version as integrated
into opensolaris) steadily leaks memory. A fixed amount every time it updates.
Older versions of top don't leak memory at all.
--
-Peter Tribble
http://www.petertri
dd
it to the main upstream net-snmp distribution?
We've already got informal +1s from enough folks after several days discussion,
so I'll just leave this overnight for any final comments and then send
it off tomorrow
unless any objections arise.
--
-Peter Tribble
http://www.peter
ht be needed to expose all
>> kstats via snmp, so I don't want to make it an absolute requirement of
>> the project if it turns out to be too painful or impossible.
>
> Is there anything else I'm missing for this piece?
I think that's good. Give me a few moments t
mation required by the project instantation
process we can have a formal vote and get this thing underway.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
fix that a couple of times without
much success.
I note that one of the projects listed under the Observability community is
to update the network MIBs, which would be a complementary effort. Doesn't
look very active, though.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
e like - the project creation process has a number of hoops to jump through:
http://www.opensolaris.org/os/community/ogb/policies/project-instantiation.txt
specifically section 2.2. In terms of the process, we're still churning through
section 2.7 - and that's fine.
--
-Pete
y useful
for an snmp client - it needs to have stronger guarantees as to the availability
and meaning of the statistics than is typically the case.
Which is another part of the puzzle really - looking through the kstats we have
available to us, and maybe promoting the useful one
it reports same bogus information from time to time.
>
> Or are you saying that I should forget totally cpu_ticks_* and try
> to use cpu_nsec_kernel ? Dont we get same things but using different units ?
Just grab the nsec values. As I recall, the others are just lower precision
numbers
pecting exactly 100 isn't
going to work.
Accurate statistics for user/kernel/idle should be derived from:
cpu::sys:cpu_nsec_kernel
and the like.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
ox/java and
openoffice), but for normal tasks it should be fine.
I would wonder about things like name resolution - getting name lookups and dns
sub-optimal can lead to huge delays.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
mory and flushed
everything out to swap. It seemed more desirable to be able to
just tell the system to page everything back in rather than wait
for pages to be pulled in randomly on demand. (And there's
the possibility that it could all be slurped back in efficiently rather
than with
, if I can't
saturate a gigabit then I end up either (a) blaming the
disk system, or (b) complaining that the network is
overloaded.
Looking at the numbers in that article, they all seem
on the low side to me.
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
h
n
the fun!
(Not just performance, but the entire install process.)
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
perf-discuss mailing list
perf-discuss@opensolaris.org
On Fri, 2005-11-04 at 15:37, Andrei Dorofeev wrote:
> On 11/4/05, Peter Tribble <[EMAIL PROTECTED]> wrote:
> > However, there is one case in which prstat could be improved. While
> > the prstat -a output simply adds the memory of each process, if you
> > use prstat -aL
ase the apache user is running a single, but rather large,
java process.
(Just looking at this, I'm not sure why the TIME is so different.)
--
-Peter Tribble
L.I.S., University of Hertfordshire - http://www.herts.ac.uk/
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_
26 matches
Mail list logo
