memory is mostly wrong - you need to know the impact on real resource, you 
don't get that
from inside linux.

page faults?  the ones that require swapping in?  from vdisk, who cares - 
unless the vdisk
takes a page fault. from real disk, what if it's slow, you need to know what 
happened
outside linux.

CPU? sure rhel5 and sles10 partly correct, but i've yet to see documented proof 
that it
works. after managing a benchmarking organization, i stopped believing when 
someone tells
me that something works without proving it. (If you can't measure it, I'm just 
not interested)

agent? sure, very low cost agent. usually much less than .1% cpu per server, 
collecting
all the data every minute. And for servers that are idle, we can even avoid 
that .1% every
minute, because we can.  data is stored on vm, so no risk to linux.
And i really like the agents from vendors that specifically say "don't run our 
agent
unless you have a performance problem because of the overhead". So when you had 
a problem,
just jump into your time machine and start the agent as appropriate....

I heard two interesting numbers at the last SHARE.
1) Adding one IFL is estimated to cost the installation $500K with the 
software, hardware,
added storage, and admin costs. This is on the high side for most i think, but 
so take
your own number.
2) Adding an agent that consumes 1% of a CPU across the installation's targeted 
1000
servers costs 10 IFLs.

Conclusion: Installations that use a "free agent" should do their own 
arithmetic.
Installations that expect or want to grow need to manage their service and 
understand this
arithmetic.

And the best sales pitch in the world for ESALPS (if i were a saleperson) i 
could ever
come up with is:
>>4. It is now 3:00pm. How can I go back in time to find the culprit
>>application/process for the 40 minutes of hiatus?
>>
>>In zVM, I have the performance toolkit and MONWRITE data.
>>In zOS, I have RMF.





Morris, Kevin J. (LNG-DAY) wrote:

Barton, I am confused by several of your comments.  Would you please
clarify?

Trivial with ESALPS?
 - Ok, I believe you.

Cannot afford to run something on Linux?
 - How does ESALPS gather the Linux process-level data outside of
running an agent/application ON Linux?

The data that Linux logged would be wrong?
 - I assume you are referring to the inaccuracies of the "tick based CPU
time accounting"?
   - I had the understanding that RHEL5 and SLES10 resolved this issue
with the new "virtual CPU time accounting"?
 - The memory, disk, #page faults, etc. are still accurate. Correct?

Thanks,
Kevin


-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
barton
Sent: Tuesday, October 30, 2007 10:45 PM
To: [email protected]
Subject: Re: zLinux performance collection tool(s)?

this is trivial with ESALPS from Velocity Software. And you can not
afford to run something on Linux that logs this information. And the
data that Linux logged would be wrong anyway. You need something that
combines the linux and z/vm data. Which none of what you have does.



Morris, Kevin J. (LNG-DAY) wrote:


What tools are available to record/log Linux activity at the process
level?

Scenario:
1. LinuxA normally uses a steady ~30% cpu.
2. At 10:30am, it was noticed that LinuxA's cpu pegged 100% and memory


consumption increased to the point of heavy swapping 3. At 11:10am,
LinuxA's cpu went back to ~30% and memory utilization returned to
normal.
4. It is now 3:00pm. How can I go back in time to find the culprit
application/process for the 40 minutes of hiatus?

In zVM, I have the performance toolkit and MONWRITE data.
In zOS, I have RMF.

Does Linux have a comparable tool?

Thanks,
Kevin


----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
begin:vcard
fn:Barton Robinson
n:Robinson;Barton
adr;dom:;;PO 390640;Mountain View;CA;94039-0640
email;internet:[EMAIL PROTECTED]
title:Sr. Architect
tel;work:650-964-8867
note:If you can't measure it, I'm just not interested
x-mozilla-html:FALSE
url:http://velocitysoftware.com
version:2.1
end:vcard

Reply via email to