You are on page 1of 16

Commands to view the performance of the Sun servers:

I Command Name : top


Path: /opt/sfw/bin
Screen Shot:-

Load Averages: Displays the processor average load in every 1, 5, 15 minutes.


PID:- is the process id
USERNAME:- is the unix username.
THR:- indicates the number of execution threads in the process.
Threads
An application's parallelism is the degree of parallel execution acheived. In the real
world, this is limited by the number of processors available in the hardware
configuration. Concurrency is the maximum acheivable parallelism in a theoretical
machine that has an unlimited number of processors. Threads are frequently used to
increase an application's concurrency.

A thread represents a relatively independent set of instructions within a program. A thread


is a control point within a process. It shares global resources within the context of the
process (address space, open files, user credentials, quotas, etc). Threads also have
private resources (program counter, stack, register context, etc).
The main benefit of threads (as compared to multiple processes) is that the context
switches are much cheaper than those required to change current processes. Sun reports
that a fork() takes 30 times as long as an unbound thread creation and 5 times as long as
a bound thread creation.
Even within a single-processor environment, multiple threads are advantageous because
one thread may be able to progress even though another thread is blocked while waiting
for a resource.
Interprocess communication also takes considerably less time for threads than for
processes, since global data can be shared instantly.
Kernel Threads
A kernel thread is the entity that is scheduled by the kernel. If no lightweight process is
attached, it is also known as a system thread. It uses kernel text and global data, but has
its own kernel stack, as well as a data structure to hold scheduling and syncronization
information.
Kernel threads store the following in their data structure:

Copy of the kernel registers.


Priority and scheduling information.
Pointers to put the thread on the scheduler or wait queue.
Pointer to the stack.
Pointers to associated LWP and proc structures.
Pointers to maintain queues of threads in a process and threads in the system.
Information about the associated LWP (as appropriate).

Kernel threads can be independently scheduled on CPUs. Context switching between


kernel threads is very fast because memory mappings do not have to be flushed.
Lightweight Processes
A lightweight process can be considered as the swappable portion of a kernel thread.
Another way to look at a lightweight process is to think of them as "virtual CPUs" which
perform the processing for applications. Application threads are attached to available
lightweight processes, which are attached to a a kernel thread, which is scheduled on the
system's CPU dispatch queue.

LWPs can make system calls and can block while waiting for resources. All LWPs in a
process share a common address space. IPC (interprocess communication) facilities exist
for coordinating access to shared resources.
LWPs contain the following information in their data structure:

Saved values of user-level registers (if the LWP is not active)


System call arguments, results, error codes.
Signal handling information.
Data for resource useage and profiling.
Virtual time alarms.
User time/CPU usage.
Pointer to the associated kernel thread.
Pointer to the associated proc structure.

By default, one LWP is assigned to each process; additional LWPs are created if all the
process's LWPs are sleeping and there are additional user threads that libthread can
schedule. The programmer can specify that threads are bound to LWPs.
Lightweight process information for a process can be examined with ps -elcL.
User Threads
User threads are scheduled on their LWPs via a scheduler in libthread. This scheduler
does implement priorities, but does not implement time slicing. If time slicing is desired,
it must be programmed in.
Locking issues must also be carefully considered by the programmer in order to prevent
several threads from blocking on a single resource.
User threads are also responsible for handling of SIGSEGV (segmentation violation)
signals, since the kernel does not keep track of user thread stacks.
Each thread has the following characteristics:

Has its own stack.


Shares the process address space.
Executes independently (and perhaps concurrently with other threads).
Completely invisible from outside the process.
Cannot be controlled from the command line.
No system protection between threads in a process; the programmer is responsible
for interactions.
Can share information between threads without IPC overhead.

Priorities

Higher numbered priorities are given precedence.


Zombie Processes
When a process dies, it becomes a zombie process. Normally, the parent performs a
wait() and cleans up the PID. Sometimes, the parent receives too many SIGCHLD signals
at once, but can only handle one at a time. It is possible to resend the signal on behalf of
the child via kill -18 PPID. Killing the parent or rebooting will also clean up zombies.
The correct answer is to fix the buggy parent code that failed to perform the wait()
properly.
Aside from their inherent sloppiness, the only problem with zombies is that they take up a
place in the process table.
For more information on threads, visit the following URL:
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/MTP/p46.html
Native LWP Priorities
In Solaris an LWP's priority influences how many CPU cycles a thread receives relative
to other threads. The Solaris scheduler uses priority (among other factors) to determine if
one thread should preempt another thread, how often a thread runs, and how long a thread
runs. Native LWP priorities are assigned by the priocntl() system call.

PRI:- PRI is the current priority of the process.


NICE:- is the nice amount (in the range \-20 to 20).
If you run CPU-intensive processes, you should familiarize yourself with the nice and,
renice, and pbind commands.
Every process has a nice value in the range from 0 to 39, with 39 being the nicest. Nicer
processes tend to yield the CPU to less nice processes. By default, user processes start
with a nice value of 20. You can see the current nice value of a process in the NI column
of a ps listing.
The nice command starts a process with a non-default nice value. There are two versions
of the nice command: one built in to the csh, and one in /usr/bin/nice.
Example:
nice +n command
nice +19 TRAINREC ... # nice value will be 39

n is 20 less than the nice value to be used to run command.


SIZE:- is the total size of the process (text, data, and stack).
RES:- RES is the current amount of resident memory.
STATE:- is the current state.
cpuN Process is running on CPU N.
sleep Sleeping: process is waiting for an event to
complete.
run Runnable: process in on run queue.
zombie
Zombie state: process terminated and parent not
waiting.
stop Process is stopped.
TIME:- is the number of system and user cpu seconds that the process has used.
CPU:- is the raw percentage and is the field that is sorted to determine
the order of the processes.
COMMAND:- is the name of the command that the process is currently running.
II Command name: prstat
report active process statistics

PID:- The process ID of the process.


USERNAME:- The real user (login) name or real user ID.
SIZE:- The total virtual memory size of the process, including all mapped files and
devices
RSS:- Sort by resident set size
STATE:cpuN Process is running on CPU N.
sleep Sleeping: process is waiting for an event to
complete.

run Runnable: process in on run queue.


zombie
Zombie state: process terminated and parent not
waiting.
stop Process is stopped.
PRI:- The priority of the process. Larger numbers mean higher priority.
NICE:- Nice value used in priority computation. Only processes in certain
scheduling classes have a nice value.
TIME: the cumulative execution time for the process.
CPU: The percentage of recent CPU time used by the process.
PROCESS:- The name of the process (name of executed file).
LWPID The lwp ID of the lwp being reported.
NLWP The number of lwps in the process.
USR The percentage of time the process has spent in user mode.
SYS The percentage of time the process has spent in system mode.
TRP The percentage of time the process has spent in processing system traps.
TFL The percentage of time the process has spent processing text page faults.
DFL The percentage of time the process has spent processing data page faults.
LCK The percentage of time the process has spent waiting for user locks.
SLP The percentage of time the process has spent sleeping.
LAT The percentage of time the process has spent waiting for CPU.
VCX The number of voluntary context switches.
ICX The number of involuntary context switches.
SCL The number of system calls.
SIG The number of signals received.
The following command reports the five most active superuser processes

The following command reports the five most active process of oracrp4s

Displaying Verbose Process Usage Information


The following command displays verbose process usage information about processes with lowest resident set sizes owned

by users root and oracrp4


root@n1 # prstat -S rss -n 5 -vc -u root,oracrp4
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG
PROCESS/NLWP
4 root 0.0 0.0 - - - - 0.0 - 18 0 0 0 cluster/1064
24733 root 0.0 0.0 - - - - 90 - 0 0 0 0 sh/1
19174 root 0.0 0.0 - - - - 63 - 0 0 0 0 sh/1
29388 root 0.0 0.0 - - - - 56 - 0 0 0 0 sh/1
2428 root 0.0 0.0 - - - - 93 - 0 0 0 0 sh/1
Total: 158 processes, 1769 lwps, load averages: 0.20, 0.18, 0.18
root@n1 #

III Command: vmstat

kthr: Report the number of kernel threads in each of the three following states:
r in run queue
b blocked for resources I/O, paging, and so forth
w swapped

memory: Report on usage of virtual and real memory.


swap amount of swap space currently available (Kbytes)
free size of the free list (Kbytes)
page: Report information about page faults and paging
activity. The information on each of the following
activities is given in units per second.
re
mf
pi
po
fr
de
sr

page reclaims - but see the -S option for how this field is modified.
minor faults - but see the -S option for how this field is modified.
kilobytes paged in
kilobytes paged out
kilobytes freed
anticipated short-term memory shortfall (Kbytes)
pages scanned by clock algorithm

isk Report the number of disk operations per second. There


are slots for up to four disks, labeled with a single
letter and number. The letter indicates the type of
disk (s = SCSI, i = IPI, and so forth); the number is
the logical unit number.
faults
Report the trap/interrupt rates (per second).
in interrupts
sy system calls
cs CPU context switches
cpu Give a breakdown of percentage usage of CPU time. On
MP systems, this is an average across all processors.
us user time
sy system time
id idle time
IV Command: iostat xtc -5 1

devicename of the disk


r/s reads per second
w/s writes per second
Kr/s kilobytes read per second
Kw/s kilobytes written per second
wait average number of transactions waiting for service
(queue length)
actv average number of transactions actively being serviced
(removed from the queue but not yet completed)
svc_t average service time, in milliseconds
%w percent of time there are transactions waiting for
service (queue non-empty)
%b percent of time the disk is busy (transactions in progress)
iostat -En

V Command: sar 1 5
System activity reporter:

Reports activity after every 1 second 5 times and gives the average.
%usr: portion of time running in user mode
%sys: portion of time running in system mode
%wio: idle with some process waiting for block I/O
%idle: idle.
VI Command: psrinfo

Shows the status of the processors and the time since when the processors are online.
VII Command: prtconf
Used to check the total memory and other configurations of the server:
The second line shows the total memory installed in the computer in Megabytes.

VIII Command: prtdiag


Used to check the diagnostic information about all the hardware components of the
server:
This gives information about the
*CPU
*Memory Configuration
* IO cards
*Environmental status [CPU temperatures]
*Keyswitch position
* LED status
*FAN module status and speed in RPM
*Power supply status.

Processor Temperatures:

Status of Fan bank and Power Supplies:

You might also like