Pages: 1 2 3 4

EXAMPLE
As an example of a case that you may run into, which coincidently I have ran into on Linux distros as far back as I can remember is with the Flash Plug in technology and available browsers in Linux. Once you install the flash plugin following the directions in the readme file that comes with the Flash plugin, you’ll, unfortunately, notice the plugin is significantly less powerfull for Linux then Windows. For one, the version of flash available for Linux will be older then the latest one available for Windows. The second limitation, is that the other player from Adobe, Shockwave, is not available for FireFox at the time of this writing. So often enough, you’ll run into situations online where you can’t view the latest flash of a site despite the fact that you have flash installed. And here is where the issue may popup for you on your Linux distribution. At the point where flash is starting up, FirsFox would repeatedly freeze on me to the point where it’s unusuable. Coincidently, so does my entire system. Since this happened too often for me, I followed this procedure:

• I started ‘konsole‘ . This took long enough on it’s own since my system was now crawling due to the lock up (And what I thought was FireFox to be causing it)
• I typed ‘uptime‘ as this is simpler and requires less resources then other commands so it typically returns results on how busy my system is, quicker then most other commands, which is what I wanted at this point.

$ uptime
18:29:04 up 1:03, 3 users, load average: 0.48, 0.26, 0.14
$

• This told me the summary average value of how busy my system was. In my case it was about 4, which, if you don’t have much familiarity with load averages at this point, is quite high. A value of 1 typically means 100% busy and higher means you’ll start to see significant delays in how fast your applications will respond to you. Typically, your system will be usable under values higher then 1 but you’ll start to see delays you might not like or be comfortable with. For this reason it’s good to keep your load average under 1 at all times.

• I needed to find out what is causing the most CPU usage at this point and therefore causing the high load. To find this out I typed ‘top‘.
• Once in ‘top‘, I typed ‘?‘ to get to ‘top’ help since I forgot the command that sorts the fields by % CPU. Found the command is ‘O‘ (capital ‘ohh’) and pressed ‘Esc‘ key to exit the help menu.
• Now that I was back to the main ‘top‘ screen, I typed ‘O‘ which opened up a menu with options for sorting I could use.
• I typed ‘K‘ from the above list, which sorted output of ‘top‘ by CPU % usage.
• Having sorted the ‘top’ output by CPU usage, it was now apparent it was the FireFox binary ‘firefox-bin’ executable, (FireFox) causing the highest CPU usage.
• At this point I allowed the ‘top‘ refresh a few times to ensure ONLY ‘firefox-bin’ was causing the high load and CPU % usage, which it turned out that it was. The reason for this is that ALL applications use 100% of CPU at some point or another however only those that use 100% of CPU constantly for any long period of time will cause any appreciable system load.
• At this point, I wanted to see if the drive itself isn’t also contributing to the high load. For this I used ‘hdparm -tT /dev/hdb‘ :

$ hdparm -tT /dev/hdb
/dev/hdb:
Timing cached reads: 2148 MB in 2.00 seconds = 1073.85 MB/sec
Timing buffered disk reads: 150 MB in 3.23 seconds = 46.49 MB/sec
$

• This command tells me how fast it could read to and from a disk. Typical speeds for IDE I found were around the 50MB/s mark, which is very good and about 60MB/s for SATA. These speeds are very good. If you see less then 5MB/s then you can be certain there is something writing to your disk. Another reason for low IDE speeds is due to bad drive settings or IDE cable problems, or wrong cables being used on drives. For more on this, ‘hdparm‘ and what it can do for you, you can read the ‘What Drives your Linux installation? (And ‘hdparm‘, ‘hddtemp‘, ‘smartctl -a <DEVICE>‘ and ‘syslog‘ in ‘/var/log/messages‘) article here.
   
• (NOTE: For this step I could have also used ‘smartctl -a /dev/hdb‘ to get other drive information. This utility also prints detailed drive information and statistics which can be used in diagnosis.)
•  
• I was relatively certain then, that the load is caused nearly purely by excessive %CPU usage. I wasn’t sure how it’s causing this high CPU usage other then the fact I loaded a Flash site but I wasn’t interested in the exact details since most likely, even if I did find out the reason, neither Adobe nor FireFox developers would do anything right away to resolve the issue within a couple of days or even weeks to do me any good.

• At this point I knew the problem was with ‘firefox-bin‘ using excessive CPU resources. To verify that memory usage isn’t the culprit as well, I went back into ‘top‘ to check on this. I did this by typing ‘top‘ and this time used ‘O‘ followed by ‘n‘ to sort by memory % usage. This wasn’t an issue and top memory usage from running ‘free‘ on the command line confirmed this. Another way to find out if memory usage is a problem you can sort by either ‘VIRT’, ‘RES’ or ‘SHR’ in ‘top‘ which can tell you more details on usage. In general looking into memory usage beyond a ‘general indication’, is a whole new topic and too vast for this modest topic here. 🙂

All in all, any information viewed or retrieved by unix/linux commands is interpretive since memory usage is often shared by other modules in memory, meaning that what you see in utilities is not ‘really’ the amount of memory an application is using but most likely significantly less. Another thing I could have done is to look into ‘proc/meminfo‘ by running ‘cat /proc/meminfo‘ which would tell me more results and a brakedown on memory usage on my system.
 

SOLUTION

Because I did not want to drift off of what I was doing and start chasing this problem in detail, I just needed to resolve the issue, get my browser to respond again and go about my business. Because I could not exit from FireFox, being frozen and all, I decided to kill it instead. You can also do this from ‘top‘ by following the below steps:
 

1. Run ‘top‘ from command line and type ‘k‘. This will ask you which PID you want to kill.
2. Type the ‘PID’ (Process ID) of the item you want to kill. The PID’s are available from the first column of ‘top’.
3. Once you type the PID, hit enter. At this point, you should no longer see the particular process (In this case ‘firefox-bin’) running and you should see a gradual drop in load and a more responsive system.
4. Restart FireFox and avoid browsing to the problematic site. 🙂
5. Another topic you can view on how to avoid this situation and having your system ‘over loaded’ by a rogue issues is to look for my article here on ‘The effects and consequences of prioritizing Linux applications’ and 'Server optimization' articles in the near future.

 

This method of investigation may be helpful to you in most load related issues. Of course, most of the other utilities listed here can also assist if you find the above brief in investigation example not sufficient to identify a problem on your system. 

Cheers!
Tom K.

Pages: 1 2 3 4