25 lab5unixa

25 lab5unixa
of 3
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Performance tuning part A:Troubleshooting without DTrace Joakim Fallsj¨o  <  > November 27, 2005 $Id: ptune-a.tex,v 1.1 2005/11/27 18:59:01 fallsjo Exp $ Abstract This exercise is aimed to give an introduction to a some debuggingand performance analysis tools. This lab will demonstrate the usageof some of the tools available. 1 Related reading Dtrace webcast 2 Preparatory exercises Make shure that you have a working unix environment, that includes: ã  Download DTraceToolkit from munity/dtrace/dtracetoolkit/ ã  Ask the instructor to prepare your server with a problem. 3 Instructions All output should be saved to a file for further reference. Use script to savea transcript of your session. 4 Exercises This is a demonstration of dtrace analysis vs other tools on Solaris 10. Note:This document is not written by Sun. Note 2: This is a ripoff from a sourcethat will be revealed at the end of this excercise.1  4.1 A Classic Problem The following shows a system suffering a classic performance problem. Al-though this fault has been delibrately created for this demonstration, thistype of problem is common.A few commands are run to show the system is under heavy CPU load, # uptime# vmstat 1 This is a single CPU system, so a load average above 1.0 would indicatepotential CPU saturation, with 100% utilisation. The output of vmstatsupports this, it shows no idle time, and some threads queueing up for these1 second averages.Lets run prstat to identify the process responsible, # prstat Hmm, looking at the CPU column doesn’t explain our 100% utilisedsystem, the processes we can see may add up to far less than 100% CPU.It’s possible the CPU is consumed by various kernel threads that arenot represented as processes. For example, CPU consumed by interruptthreads can now be checked in Solaris 10 by the intrstat command (whichuses DTrace), # intrstat 5 This shows I’m losing some CPU to my network card. This hasn’t ex-plained the missing CPU time, but it’s really useful to be able to get detailson interrput CPU usage anyway.Another place the CPU can vanish to is to satisfy TLB and TSB misses- virtual to physical address translation. trapstat can show us, # trapstat -T 1 Well, for good measure we should check other areas of the system: mem-ory, disk I/O, and network usage. I’ll use swapinfo to check memory, # swapinfo So plenty of available RAM.Now iostat to check disk activity, # iostat -xnmpz 5 Not much disk activity there.Now nicstat to check network usage, # nicstat 1 And not much network activity either.After all that, we know the CPU is fairly busy but have little idea why. 4.2 Bring on truss truss  needs to either run the program, or to be given a PID to examine.We already checked processes using prstat, and there was no process that2  explained where all the CPU had gone. The highest we saw was a bash shell.Use truss on that PID associated with that instance of bash. # truss -p <PID> The above output scrolled very fast with much of the same. We can seea fork1() and a SIGCLD so we ought to follow children, # truss -fp <PID> The above output shows the child is a simple command. Lets concentrateon those execs only, # truss -ftexec -p <PID> By now you should have an idea of what the problem might be.3

How to Study

Jul 23, 2017
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks