Get the CPU information in Linux

Multi-core CPU processors are common nowadays, including dual-core processors, quad-core processors, and hexa-core processors. Also, many server physical machines are equipped with more than one CPU processor. In order to find the number CPUs, and the number of cores per CPU, you can refer to /proc/cpuinfo. A sample /proc/cpuinfo of HP Proliant DL 380 G7 server is as follows. 

To find the number of physical CPUs:

$ cat /proc/cpuinfo | grep "^physical id" | sort | uniq | wc -l
2

To find the number of cores per CPU:

$ cat /proc/cpuinfo | grep "^cpu cores" | uniq
cpu cores : 4

The total number of processors available is the number of physical CPUs multiplied by the number of cores per CPU.

To find the total number of processors:

$ cat /proc/cpuinfo | grep "^processor" | wc -l
16

Note that Intel Xeon 5600 series processors have Intel Hyper-Threading capability. So each core shows up as "two" processors in Linux, and thus the total processor count seen by Linux is 16 (= 2 x 4 x 2).

Compare Files between two directories using md5sum

If you come across situation where you need to compare two directories in two different servers. md5sum command can be used, which will generate md5sum of files in directories and write it to one file. In turn that file can be used to check md5sum at destination. 

Run below command at source location:

find /opt/ -type f -print0 | xargs -0 md5sum > /root/checksums_backup.md5

Once you run above command, it will create /root/checksums_backup.md5 file. You can copy this file to destination server and run below command to check md5sum. 
Note: Source and Destination server should have the same directory structure.

md5sum -c /root/checksums_backup.md5

After running above command, you will see "OK" and "FAILED" output. According to that you can easily make out which files are different from source location.

Check Disk Performance in Linux

We use iostat command to check the disk performance.

Reports that we get from ‘iostat’ are really useful but I myself had a little bit of trouble when trying to interpret the results while using the the first time.

I usually use the iostat command with the following switches:

iostat –d –x <interval>

Where in…

-d = gets rid of the CPU stats so that we can easily concentrate on the I/O only

-x = some additional info like ‘await’ and ‘svctm’ (will discuss them later)

<interval> = this is time in seconds, so every number of <interval> seconds you will get a new ‘iostat’ report

Let’s now see a sample output of ‘iostat’:

If we look at stats above usually we would look at %util and if we see close to 100% it can identify the problem for a single disk setup, but not in a usual multi-disks scenario.

Columns that we look at it in order to identify the problem will be:

syvctm: The average service time (in milliseconds) for I/O requests that were issued to the device

await: The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.

This basically means:

 await = syvctm + wait time in queue

Now using the above we can have a basic rule to identify an overloaded setup:

…if you can see a lot of difference in values for ‘syvctm’ and ‘await’ every now and then, that can tell you about I/O requests being going into long waits and this should help you identify the problem.