Mike Gerdts wrote:
[...] However, leaving these same people blind is
not a good approach either. We have long-term history of vmstat data
and would prefer to continue to use this as an indicator.
Yeah, change always leads to challenges. So, just add your old %wio to
your old
%idle, and your a
Stub it out with LD_PRELOAD and I'll bet that you still have the same
performance problem.
Anything that feels the need to log 4000 times/sec is going to be
causing the performance problem with the log writing code, not the
getpid. I expect that your system could call getpid more than a
million t
On Wed 18 Oct 2006 at 08:01PM, Jason King wrote:
> We have a third party library (which we do not have the source for),
> that calls getpid() everytime it logs something. Unfortunately, in
> the application where the library is being used, this results in over
> 4000 getpid calls/sec (accounting f
We have a third party library (which we do not have the source for), that calls
getpid() everytime it logs something. Unfortunately, in the application where
the library is being used, this results in over 4000 getpid calls/sec
(accounting for over half the total system calls/sec being made by
Adrian,
I agree. This is a good opportunity to discuss performance measurement
issues.
However, you asked if I would fix your particular issues while fixing
the bug that Mike found. I don't want to mislead anybody, so my
response was simply that I don't presently have the time to address
these a
I understand, but since this is "perf-discuss" I thought it was a good
opportunity to discuss this performance measurement issue.
Thanks Adrian
On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Adrian,
I agree that these metrics would be useful and nice to have; however,
their implemen
Mike,
> As "meaningless" as iowait is/was, there was significant value once we
> got beyond "the cpu is busy in iowait... add more boards!" Getting to
> that point paid a couple of semesters of tuition for my salesman's
> daughters.
Iowait is an overloaded term in the Solaris kernel, so the conf
Adrian,
I agree that these metrics would be useful and nice to have; however,
their implementation is outside of the scope of what I intend to
address with this fix.
I'm simply fixing the functional regression in the kstats. I can't, in
good faith, make improvements to microstate accounting and
On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It looks like I removed this when I eliminated the I/O wait percentage
calculations in Solaris 10. After taking a look at the SCCS history,
this looks like it was probably an overzealous code-deletion.
I'd say this is a bug, albeit a min
Sure, I saw what you proposed, but the real problem that we have is
that machines get io-bound and we should have metrics in Solaris that
tell us 1) a machine is io-bound, 2) which disks are responsible, and
3) which processes are being blocked
vmstat b is an approximation to the number of thread
Adrian,
Perhaps I wasn't as clear as I should have been. I'm not going
to make any change that accounts for the amount of time a thread spends
waiting for I/O. Rather, I want to re-expose a statistic which, on a
per-CPU basis, lists the number of threads blocked in biowait().
-j
On Wed, Oct 18
If you are going to fix it, could you add a microstate for iowait so
we have an accurate per process measure of blocked on diskio. I think
I filed a bug on this about 5 years ago or more... We already have a
microstate for page-in wait.
Adrian
On 10/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> w
Adrian,
biowait() still updates cpu_stats.sys.iowait. This means that Solaris
is still keeping track of the number of threads that are blocked waiting
for I/O. I see no reason not to expose this value to the user.
I certainly do not intend to re-introduce a CPU percentage of time
waiting for I/O,
Mike,
> On a related note, I have yet to see vmstat's "b" (kernel threads
> blocked on I/O) column be non-zero. This includes a large RAC
> environment where the previous measure of I/O health was (don't shoot
> the messenger!) iowait. The same workload on S9 consistently showed
> non-zero valu
The algorithm for iowait used to be something like: if idle and vmstat
b nonzero then iowait
So on Solaris 10, vmstat b is gone as well as iowait. If you want to
see how much time you are waiting for io, use iostat and add up the
times for each disk.
Here is one way it was broken, a cpu starts an
On 10/18/06, adrian cockcroft <[EMAIL PROTECTED]> wrote:
In Solaris 10, iowait is no longer measured and will be reported as
zero by existing tools. Since iowait was always a variant of idle
time, this makes no difference to usr or sys time.
iowait was always a confusing and useless metric, which
there are other options on prstat to see the usr and sys time
separately, like prstat -m
iostat, vmstat and mpstat all read the same numbers out of the kernel,
so if you see differences on the same machine then it is because they
are not synchronized and they format the results differently.
In S
Cherian,
If you want to see more detailed output, try "prstat -m", it provides
user and sys consumption, along with more detailed info.
Andrew
On Wed, 2006-10-18 at 14:04 -0700, Cherian Abraham wrote:
> Hi,
>
> I was trying to understand the prstat output, but had quite a few doubts on
> th
Hi,
I was trying to understand the prstat output, but had quite a few doubts on the
output shown.
Does the prstat CPU usage display by default for each process reflect the user
cpu time or a total of user and system cpu time ?
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NL
> Anyone have any idea why one cant use hardware
> counter profiling on non-optimized stuff?
It does not require -xO3. It requires -xOn for any acceptable value of n.
The no-optimization mode and the optimization modes are implemented
with the different codegenerators. The simple one and the sm
20 matches
Mail list logo
