MongoDB Performance Monitoring

This post is just a list of bookmarks I’ll keep to refer to for MongoDB performance analysis.

• MongoDB Monitoring

ConfigFile Basics in Haskell

Introduction

One of the first things that I reach for when writing an application that will be used outside the context of my development sandbox is a configuration library. Not having statically compiled values for variables is quite a valuable position to be in once your application has been deployed. Today’s post will take you from 0 to up and running with a package called ConfigFile that is specifically designed to serve your applications with configuration data. Most of the content in this post is lifted directly from the documentation, so you’ll be better off reading through those to gain a deeper understanding of the library. This post is more of a short-cut to get up and running.

Configuration format

If you’ve had much experience with administering windows back in the day when INI files ruled the earth, you’ll be right at home with ConfigFile. For those of you who have never seen it before, it’s really easy and you can read up on it here. Files are broken into sections which contain a list of key/value pairs - done!

For today’s example, the configuration file will look as follows:

[Location]
path=/tmp
filename=blah

We’ll end up with two keys, path and filename that have corresponding values in the Location section.

Structure

The thing I like most about the part of the application is that we can make a nice record based data structure in Haskell that will marry up to how our configuration file looks. The simple file that we’ve defined above, would look like this:

data ConfigInfo = ConfigInfo { path :: String
                             , fileName :: String
                             }

Once we fill one of these up, you can see that it’ll be pretty natural to access these details.

Reading and Building

Finally - we need to read the values out of the config file and get them into our structure. The following block of code will do that for us.

readConfig :: String -> IO ConfigInfo
readConfig f = do
   rv <- runErrorT $ do

      -- open the configuration file
      cp <- join $ liftIO $ readfile emptyCP f
      let x = cp

      -- read out the attributes
      pv <- get x "Location" "path"
      fv <- get x "Location" "filename"

      -- build the config value
      return (ConfigInfo { path = pv
                         , fileName = fv
                         })

   -- in the instance that configuration reading failed we'll
   -- fail the application here, otherwise send out the config
   -- value that we've built
   either (\x -> error (snd x)) (\x -> return x) rv

There’s a few interesting points in here to note. The Error Monad is being used here to keep track of any failures during the config read process. runErrorT kicks this off for us. We then use readfile to open the config file with a sane parser that knows how to speak INI. Pulling the actual strings from the config is done by using get. From here, it’s just wrapping the values up ready to send out. The final call is to either. Leaving the Error Monad, we’re given an Either (left being the error, right being the value). I’ve used either here so I can provide an implementation for either scenario. If an error occurs (the first lambda) then I just toast-out of the application. If we get a config value back (the second lambda), that’s what gets returned.

Conclusion

That’s all there is to that. Remember, you won’t escape from the IO Monad which is why the read function’s return type has IO. When you want to use these values, it’ll need to be within do constructs:

main :: IO ()
main = do
   config <- readConfig "test.cfg"
   putStrLn $ "The path value is: " ++ (path config)
   putStrLn $ "The filename value is: " ++ (fileName config)

Cheers.

Making Sense of the Linux "top" Report

Introduction

Working in a Linux environment for more and more of the day, it pays to know your tools really well. One tool that I use frequently to understand what a machine is doing is the top command. Today’s post will take you through all of the figures on this report to help you understand what each means.

The Command

The top command is a very common tool used to “display Linux tasks” as the man page so helpfully tells us. Issuing this command at the shell will present the user with a few rows of figures followed by a list of all running processes on the system. Here is an extract of the report (just the upper lines that this post will focus on).

Breaking Down the Summary

You can see from the excerpt above that quite a lot of information is packed into this part of the report. To breakdown this report, I’ll just got through it line by line.

top - 20:52:24 up 24 min,  2 users,  load average: 0.93, 1.01, 0.93

The first line tells us the following:

• The current time (20:52:24)
• The machine’s up time (24 min)
• How many user sessions currently (2)
• The system’s load average for the last minute (0.93), last 5 minutes (1.01) and last 15 minutes (0.93)

The system load average is an interesting one. A general rule of thumb is to investigate if you’re seeing averages above 0.7. An average of 1.0 suggests that just enough work is getting processed by the machine, but is leaving you no headroom to move. Seeing a load of 5 and above is panic-time, systems stalling, trouble. For more information about these load values, take a look at Understanding Linux CPU Load - when should you be worried?

Tasks: 111 total,   1 running, 110 sleeping,   0 stopped,   0 zombie

The second line tells us the following:

• The total number of tasks (111)
• How many of those tasks are running (1)
• How many of them are sleeping (110)
• How many of them are stopped (0)
• and, How many of them are waiting to be stopped (or zombie) (0)

%Cpu(s):  12.3 us,  4.9 sy,  0.0 ni, 81.8 id,  0.7 wa,  0.0 hi,  0.3 si,  0.0 st

The third line gives you a point in time view of how busy the CPU is and where its cycles are being used. It tells us the percentage of CPU being used for:

• User applications (12.3 us)
• System applications (4.9 sy)
• Applications that have had their “nice” value adjusted (0.0 ni)
• Unused or Idle (81.8 id)
• Waiting for I/O operations (0.7 wa)
• Handling hardware interrupts (0.0 hi)
• Handling software interrupts (0.3 si)
• Stolen by the hypervisor (0.0 st)

KiB Mem:   8129072 total,  1402664 used,  6726408 free,    69512 buffers
KiB Swap:  9920508 total,        0 used,  9920508 free,   620016 cached

The fourth and fifth lines deal with memory and swap utilisation. It tells us the following:

• Total
• Used
• Free
• Buffers
• Cached

That’s it for the summary of the machine’s activity. These are all the aggregate values which will give you an “at a glance” feel for how the machine is going. The next part of this post will be all about reading specific information from the process report. Here’s an excerpt of the report.

Breaking Down the Process Report

To interrogate a single process, you can use the details within the process report. It will list out all of the processes currently managed by your system. The report columns as you look at it will provide the following information:

• The process ID (PID)
• The user who owns the process (USER)
• The priority (PR)
• The nice value (NI)
• Virtual memory used by the process (VIRT)
• Physical memory used by the process (RES)
• Shared memory for the process (SHR)
• Status of the process (S) (Sleeping, Running, Zombie)
• Percentage of CPU used by this process (%CPU)
• Percentage of memory used by this process (%MEM)
• The time that this process has been active (TIME+)
• The name of the process (COMMAND)

That’s it for the “top” command in Linux. Remember, always read the man pages for commands that you want to learn more about!

More Beautiful Text

Getting a wider array of fonts into your website is a pretty simple task these days. There’s quite a selection of fonts that you can use offered on the web. Just take a look at Google’s repository to see what I’m talking about.

Once you’ve selected the font that’s right for your application, you can import it to pages using the following directive:

@import url(http://fonts.googleapis.com/css?family=Droid+Sans:400,700);

… and then finally use it in your css directives.

font-family: "Droid Sans", arial, verdana, sans-serif;

Easy.

FASM - Flat Assembler

A quick reminder post to myself to go and look at Flat Assembler. Interest was sparked initially from a article that was more of an x86 assembly tutorial here