Part -2
In this part, we are going to see the diagnosing out of memory issues and high I/O wait time!
Diagnosing High I/O Wait.
When you see high I/O wait, one of the first things to check whether the machine is using a lot of swap.
Since the hard drive is much slower than RAM, when the system runs out of RAM and starts using swap, the performance of almost any machine suffers. Anything that wants to access the disk has to compete with swap for disk I/O. So first diagnose whether you are out of memory and, if so, manage the problem there. If you do have plenty of RAM, you will need to solve this problem out which program is consuming the most I/O.
It can sometimes be difficult to figure out exactly which process is using the I/O, but if there are multiple partitions on the system, it can be narrowed it down to figuring out which partition most of the I/O is on. To execute this, we need iostat program, which is provided by the sysstat.
When there is a system under heavy I/O load, the first step is to look at each of the partitions and identify which partition is getting the heaviest I/O load. Say, for example, that we have a database server and the database itself is stored on /dev/sda3. Here we can see that the bulk of the I/O is coming from there, you have a good clue that the database is likely consuming the I/O.
DNS Troubleshooting
Why won’t the hostnames resolve server issues?
Let’s see!
DNS Server Side Troubleshooting
Understanding dig output
Although nslookup is a useful tool for DNS troubleshooting, when it comes to DNS servers, using dig gives proper thing. Both tools should be available on average Linux system, but using dig for DNS server troubleshooting because of all of the extra information it gives by default. The output from dig a lot closer to the actual DNS response from the server.
This is the sample dig output.
By default dig attempts to resolve a hostname into an IP, but you can also have dig bring back any other DNS record for a domain. To do this, just add the record type to the end of your query (i.e., NS, MX, TXT).
It not only tells us when we ran the query and how long it took (which can be useful when we are diagnosing slow DNS servers), it also tells us what DNS server did the search for us.
This can be handy in case we are trying to track down a problem where one DNS server has stale records and another doesn’t, because we can tell which DNS server our client contacted for each request.
That’s all folks!
