vparihar01/performance_commands.sh

## performance_commands.sh
## This is a quick way to view the load averages, which indicate the number of tasks (processes) wanting to run.
## On Linux systems, these numbers include processes wanting to run on CPU,
## as well as processes blocked in uninterruptible I/O (usually disk I/O).
uptime

## This views the last 10 system messages, if there are any. Look for errors that can cause performance issues.
## The example above includes the oom-killer, and TCP dropping a request.

dmesg | tail
## Short for virtual memory stat, vmstat(8) is a commonly available tool
## Columns to check:
## r: Number of processes running on CPU and waiting for a turn. This provides a better signal than load averages for
#determining CPU saturation, as it does not include I/O. To interpret: an “r” value greater than the CPU count is saturation.
## free: Free memory in kilobytes. If there are too many digits to count, you have enough free memory.
#The “free -m” command, included as command 7, better explains the state of free memory.
## si, so: Swap-ins and swap-outs. If these are non-zero, you’re out of memory.
## us, sy, id, wa, st: These are breakdowns of CPU time, on average across all CPUs.
#They are user time, system time (kernel), idle, wait I/O, and stolen time (by other guests, or with Xen, the guest's own isolated driver domain).
vmstat 1

## This command prints CPU time breakdowns per CPU, which can be used to check for an imbalance.
## A single hot CPU can be evidence of a single-threaded application.
mpstat -P ALL 1

## Pidstat is a little like top’s per-process summary, but prints a rolling summary instead of clearing the screen.
## This can be useful for watching patterns over time, and also recording what you saw (copy-n-paste) into a record of your investigation.
pidstat 1

## r/s, w/s, rkB/s, wkB/s: These are the delivered reads, writes, read Kbytes, and write Kbytes per second to the device.
#Use these for workload characterization. A performance problem may simply be due to an excessive load applied.
## await: The average time for the I/O in milliseconds. This is the time that the application suffers,
#as it includes both time queued and time being serviced. Larger than expected average times can be an indicator of device saturation, or device problems.
## avgqu-sz: The average number of requests issued to the device. Values greater than 1 can be evidence of saturation
#(although devices can typically operate on requests in parallel, especially virtual devices which front multiple back-end disks.)
## %util: Device utilization. This is really a busy percent, showing the time each second that the device was doing work.
#Values greater than 60% typically lead to poor performance (which should be seen in await),although it depends on the device.
#Values close to 100% usually indicate saturation.
iostat -xz 1

##buffers: For the buffer cache, used for block device I/O.
##cached: For the page cache, used by file systems.
free -m

## Use this tool to check network interface throughput: rxkB/s and txkB/s, as a measure of workload,
#and also to check if any limit has been reached. In the above example, eth0 receive is reaching 22 Mbytes/s,
#which is 176 Mbits/sec (well under, say, a 1 Gbit/sec limit).
sar -n DEV 1

##This is a summarized view of some key TCP metrics. These include:
##active/s: Number of locally-initiated TCP connections per second (e.g., via connect()).
##passive/s: Number of remotely-initiated TCP connections per second (e.g., via accept()).
##retrans/s: Number of TCP retransmits per second.
##The active and passive counts are often useful as a rough measure of server load: number of new accepted connections
##(passive), and number of downstream connections (active). It might help to think of active as outbound,
##and passive as inbound, but this isn’t strictly true (e.g., consider a localhost to localhost connection).
sar -n TCP,ETCP 1

##The top command includes many of the metrics we checked earlier. It can be handy to run it to see if anything looks wildly
##different from the earlier commands, which would indicate that load is variable
top
	## This is a quick way to view the load averages, which indicate the number of tasks (processes) wanting to run.
	## On Linux systems, these numbers include processes wanting to run on CPU,
	## as well as processes blocked in uninterruptible I/O (usually disk I/O).
	uptime

	## This views the last 10 system messages, if there are any. Look for errors that can cause performance issues.
	## The example above includes the oom-killer, and TCP dropping a request.

	dmesg \| tail
	## Short for virtual memory stat, vmstat(8) is a commonly available tool
	## Columns to check:
	## r: Number of processes running on CPU and waiting for a turn. This provides a better signal than load averages for
	#determining CPU saturation, as it does not include I/O. To interpret: an “r” value greater than the CPU count is saturation.
	## free: Free memory in kilobytes. If there are too many digits to count, you have enough free memory.
	#The “free -m” command, included as command 7, better explains the state of free memory.
	## si, so: Swap-ins and swap-outs. If these are non-zero, you’re out of memory.
	## us, sy, id, wa, st: These are breakdowns of CPU time, on average across all CPUs.
	#They are user time, system time (kernel), idle, wait I/O, and stolen time (by other guests, or with Xen, the guest's own isolated driver domain).
	vmstat 1

	## This command prints CPU time breakdowns per CPU, which can be used to check for an imbalance.
	## A single hot CPU can be evidence of a single-threaded application.
	mpstat -P ALL 1

	## Pidstat is a little like top’s per-process summary, but prints a rolling summary instead of clearing the screen.
	## This can be useful for watching patterns over time, and also recording what you saw (copy-n-paste) into a record of your investigation.
	pidstat 1

	## r/s, w/s, rkB/s, wkB/s: These are the delivered reads, writes, read Kbytes, and write Kbytes per second to the device.
	#Use these for workload characterization. A performance problem may simply be due to an excessive load applied.
	## await: The average time for the I/O in milliseconds. This is the time that the application suffers,
	#as it includes both time queued and time being serviced. Larger than expected average times can be an indicator of device saturation, or device problems.
	## avgqu-sz: The average number of requests issued to the device. Values greater than 1 can be evidence of saturation
	#(although devices can typically operate on requests in parallel, especially virtual devices which front multiple back-end disks.)
	## %util: Device utilization. This is really a busy percent, showing the time each second that the device was doing work.
	#Values greater than 60% typically lead to poor performance (which should be seen in await),although it depends on the device.
	#Values close to 100% usually indicate saturation.
	iostat -xz 1

	##buffers: For the buffer cache, used for block device I/O.
	##cached: For the page cache, used by file systems.
	free -m

	## Use this tool to check network interface throughput: rxkB/s and txkB/s, as a measure of workload,
	#and also to check if any limit has been reached. In the above example, eth0 receive is reaching 22 Mbytes/s,
	#which is 176 Mbits/sec (well under, say, a 1 Gbit/sec limit).
	sar -n DEV 1

	##This is a summarized view of some key TCP metrics. These include:
	##active/s: Number of locally-initiated TCP connections per second (e.g., via connect()).
	##passive/s: Number of remotely-initiated TCP connections per second (e.g., via accept()).
	##retrans/s: Number of TCP retransmits per second.
	##The active and passive counts are often useful as a rough measure of server load: number of new accepted connections
	##(passive), and number of downstream connections (active). It might help to think of active as outbound,
	##and passive as inbound, but this isn’t strictly true (e.g., consider a localhost to localhost connection).
	sar -n TCP,ETCP 1

	##The top command includes many of the metrics we checked earlier. It can be handy to run it to see if anything looks wildly
	##different from the earlier commands, which would indicate that load is variable
	top