Monday, February 27, 2012

Run a VirtualBox machine in the background

Most people use SSH and console to access linux machines - physical or virtual boxes! Thus for you guys who use virtualbox might find it really cumbersome to have to fire off a GUI to access the machine, even if you decide to minimise the window and SSH directly from the client. Luckily there is a solution to run a VirtualBox machine in the background.

You can use VBoxManage to start the machine in the background by running the following command:

VBoxManage startvm my_machine --type headless


Just remember to setup an SSH server on the virtualbox so that you will be able to access it remotely!

Disable Browsing History in Google Apps

If you haven't heard already, Google is about to start keeping track of every single web search you perform and associate it to your name. (It already does this, but the results are anonymised months later; with these changes, your name and searching habits will be etched in stone.) Please take the time to protect your online privacy before March 1st.

This article describes the process to disable this Google 'feature', whether you use Google Apps for your custom domain, and also if you have just a single user Google Account.

Deleting your browsing history before March 1 when Google's new privacy policy comes into effect will limit Google's ability to track and record your every move online. The process for a single user account is simple. Follow the steps below:

  1. Go to the google homepage and sign into your account.
  2. Click the dropdown menu next to your name in the upper-right hand corner of your screen.
  3. Click accounts settings
  4. Find the "Services section"
  5. Under "Services" there is a sub-section that reads "View, enable, disable web history." Click the link next to it that reads: "Go to Web History."
  6. Click on "Remove all Web History"

When you click on "Remove all Web History," a message appears that says " Web History is Paused." What this means is that while Google will continue gathering and storing information about your web history it will make all data anonymous, that is, Google will not associate your Web History information with your online accounts and will therefore be unable to send you customized search results.
If you have a Google Apps account, follow these steps:

1. Visit the following URL: https://www.google.com/a/cpanel/<your_domain>
2. Click on 'Organisation & Users' and then the 'Services' tab:
3. Find the Web History service and turn it off:

By following these steps Google will not be able to associate your name with web history. If you are concerned about the privacy, please share this article.

Thursday, February 09, 2012

Detecting memory leaks in Linux

So after a couple of weeks you notice that your beefed-up Linux box is running dry on memory. Then you restart the box and the same thing happens again after another couple of weeks. If this sort of thing happened to you, then your system is suffering from a potential memory leak.

In a previous article we discussed how to find out the exact memory usage of a Linux process using 'pmap'. Therefore if we use pmap across a long enough time period, we can find out whether the memory usage of the process is increasing, indicating a memory leak. The figure below indicates a typical memory leak:
For a single process this is very easy to accomplish with pmap - the challenge starts when we have no idea which process is leaking. Therefore we need a script to scan all processes and gathering all their memory usage over time. As such I devised the following script which accomplishes this task:

#!/bin/bash
 
# Author: James Attard [jamesattard.com]
# Date: 17/01/2012
# This script will check the real memory each process is consuming to determine any memory leaks.
 
# Get list of processes
ps -ef | grep "myprocess" | grep -v grep | awk '{print $2 ", " $8}' > /tmp/.oraps
 
numlines=`wc -l < /tmp/.pslist`
 
while read line ; do
        processline[$index]="$line"
        index=$(($index+1))
done < /tmp/.oraps
 
if [ ! -e /tmp/memory_usage.csv ];
then
        echo "Timestamp (Date Hour), PID, Process Name, Real Memory Used (KB)"
fi
 
for i in `seq 0 $(($numlines - 1))`
do
        pid=`echo ${processline[$i]} | awk '{print $1}'`
        echo `date +"%D %H"`, ${processline[$i]}, `pmap -d $pid | grep mapped | awk '{print $4}'` | sed s/.$//  >> /tmp/memory_usage.csv
done < /tmp/.oraps



The script is pretty straightforward - it will produce a list of all processes (in the above example, we are listing all processes which have string 'myprocess'). For each process, the memory usage is computed and saved in a csv file. If this script is put in an hourly cronjob, we will end up with a list of processes's memory usage over hourly interval periods.

Finally load the csv in a pivot table and produce a graph. These steps can be highlighted in the screenshots below:
This is the csv file produced by the script. Column 1 shows the timestamp of the sample, column 2 is the process ID, column 3 is the process name and last column shows the real memory usage of the process.
Load the csv in your favorite spreadsheet software and produce a Pivot Chart.
Column 1 must be the x-axis, column 2 the Series, and last column should be the y-axis.

The generated graph will have all the processes memory usage superimposed on each other. The process which is consuming an ever increasing memory over time might be leaking memory. In this case process 1184 is the culprit!

Wednesday, February 08, 2012

Monitoring Transaction Log Shipping in SQL Server

Transaction Log shipping is a great and easy way to replicate a multitude of Microsoft SQL server databases. This article will discuss how we can monitor the status of the replication. This is useful to add to the daily health checks or maybe to check the replication after one server is upgraded and one wishes to resume replication.

When Transaction Log Shipping is setup, 3 jobs are created by SQL server on the secondary database server:

  1. LSCopy - This job copies the transactions logs from the primary to the secondary server
  2. LSRestore - This will restore the transaction log which was copied by the previous job
  3. LSAlert - This job will send any alerts if there are any errors


By looking at the Job History of the LSRestore job, we can see all the transaction logs which are being restored:

This screen will also show the path of the transaction logs - one can therefore compare the timestamps and check if there is any lagging transaction logs.