HOWTO

Project Uptime : Progress Report 7 : Putting the finishing touches

We finally come to one of the last posts of Project Uptime. Now that all the components have been setup, I finally copied the wordpress directory from my old server to the new one. The only changes, I had to make after copying the files were

  1. Configure Apache to have the wordpress folder as the default directory. I did this by changing the DocumentRoot option in the vhost
  2. Changed the permissions on the wordpress directories (so that wordpress can make rewrite rule changes on the fly)

[code]sudo chmod -v 664 $WORDPRESS_DIRECTORY/.htaccess

sudo chmod 755 $WORDPRESS_DIRECTORY/wp-content [/code]

HOW TO : Configure Jboss to use hugepages in RHEL/CentOS

Most of us worry about paging to disk (swap), but if you are running a transaction intensive application the paging that happens in RAM also starts to impact the application performance. This happens due to the size of the “block” that is used to store data in memory. Hugepages allows you to store the data in bigger blocks, hence reducing the need to page while interacting with the data.

Here is how you can enable hugepages and configure jboss (actually any Java app) to use hugepages on a RHEL/CentoOS system.

OS CONFIGURATION

  1. Check if your system is capable of supporting hugepages by running[code]grep HUGETLB /boot/config-`uname -r`[/code]

    If you see the response as below, you should be good[code]CONFIG_HUGETLBFS=y
    CONFIG_HUGETLB_PAGE=y
    [/code]

  • Next check if huge pages are already being used by running[code]cat /proc/sys/vm/nr_hugepages [/code]
  1. If the response is anything other than 0, that means hugepages have already been configured.
  • Find the block size for hugepages by running[code]cat /proc/meminfo | grep -i hugepagesize [/code]
  • Calculate the amount of memory you want to dedicate to hugepages. (note: memory allocated to hugepages cannot be used by other processes in the system, unless they are configured to use it)
  1. For example, I want to dedicate 3GB of RAM for hugepages. So the number of hugepages would be[code](3*1024*1024)/2048[/code]
  • Configure the number of hugepages on the system by editing the /etc/sysctl.conf and adding the option[code]vm.nr_hugepages = 1536[/code]

    (note: I put in 1536 since that was the value I got from the above example)

  • Restart the server and check if hugepages has been enabled by running[code]cat /proc/meminfo | grep -i huge [/code]
  1. You should see something like this[code]AnonHugePages:    839680 kB
    HugePages_Total:    1500
    HugePages_Free:     1500
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    [/code]

JBOSS CONFIGURATION

  1. At this point your system is configured with hugepages and any application that is configured to use them can leverage them.  In this example, we want to configure Jboss to utilize these hugepages
  2. Add the groupid of the user that Jboss is running under to the /etc/sysctl.conf file. In my case, the jboss user group had a GID of 505, so I added this line to /etc/sysctl.conf[code]vm.hugetlb_shm_group = 505 [/code]
  3. Next allocate the memory to the user by editing /etc/security/limits.conf and allocating the memory. Again, in my case, I added the following to /etc/security/limits.conf[code]# Allocate memory for Jboss user to take advantage of hugepages
    jboss   soft    memlock 1500
    jboss   hard    memlock 1500
    [/code]
  4. Finally add the following to the Jboss startup parameters. I edited the $JBOSS_HOME/bin/run.sh file. (note: the startup file can be different based on your config) with the option[code] -XX:+UseLargePages[/code]
  5. Restart Jboss and you are good to go

note : A lot articles that I read online say that hugepages are effective when you are allocating large amounts of RAM to the application. The use case of just using 3GB above was just that.. a use case.

While I cannot personally vouch for it, a lot of users have noted that they saw >2 fold increase in performance.

HOW TO : Sync git clients across workstations using dropbox

I have recently started using git as a source control for the various scrips that I write. As I also mentioned in this post, I use dropbox to synchronize my data across workstations. Here is my setup for synchronizing git clients across multiple workstations using the same SSH keys (note: this is not a recommended setup from a security prospective. you are recommended to generate different SSH key pairs per workstation to ensure one key getting lost doesn’t compromise your entire account).

  1. Workstation 1
    1. create a directory under your dropbox root, that you want to use as your git home directory. Say DROPBOX/git
    2. Install Git for Windows, or whatever git client you want to use
    3. Change the home path on the git client by executing [code]HOME=’PATH_TO_DROPBOX/DROPBOX/git’ [/code]
    4. Check if the home path has been changed by executing [code]echo $HOME[/code]
    5. Create your SSH keys and configure your public key on the git server
  2. Workstation 2
    1. Repeat and rinse step 1 – 4 specified for workstation 1. You don’t need to create the SSH keys since the other clients will recognize the keys that dropbox would have synced up.

HOW TO : Redirect web traffic based on URL patterns in Apache

Apache configuration to redirect traffic to a particular URL based on the pattern in the URL (AKA URI). In this particular example, I want to redirect any traffic that does not have the URL starting with /application or /content to redirect to https://domain_name/application

  • Enable the rewrite module in Apache
  • Add the following conditions in the conf file[code]RewriteCond %{REQUEST_URI} !^/(application|content) [NC]
    RewriteRule ^/(.*) https://%{HTTP_HOST}/application [R,L]
    [/code]

Explanation of the rule

  • ! implies match if the string is not found
  • ^ implies start of string
  • | implies OR
  • [NC] implies not case sensitive (no case)
  • The rule will be triggered if the conditions match
  • [R,L] means external (client side) redirection and last rule to process

HOW TO : Log all commands issued in shell to syslog

Inspired from this blog post by Vaidas Jablonskis.  This tip has been tested on Redhat and Centos distributions.

If you ever wanted to log all the commands issued by users on a server, you can edit the default profile configuration to enable this

  • Edit /etc/bashrc file and add the following at the end of the file[code]PROMPT_COMMAND=’history -a >(logger -t "$USER[$$] $SSH_CONNECTION")’ [/code]
  • Log out and log back into your session
  • Now all your commands are logged in the default log file (/var/log/messages)

Project Uptime : Progress Report 5 : Getting ready for Reddit and Hacker News

A very timely post on Hacker News by Ewan Leith about configuring a low end server to take ~11million hits/per month gave me some more ideas on optimizing the performance of this website. Ewan used a combination of nginx and varnish to get the server to respond to such traffic.

From my earlier post, you might recall, that I planned on checking out nginx as the web server, but then ended up using Apache. My earlier stack looked like this Based on the recommendations from Ewan’s article, I decided to add Varnish to the picture. So here is how the stack looks currently

And boy, did the performance improve or what. Here are some before and after performance charts based on a test run from blitz.io. The test lasted for 60 seconds and was for 250 simultaneous connections.

BEFORE

  • Screenshot of Response times and hit rates. Note that the server essentially stopped responding 25 minutes into the test.
  • Screenshot of the analysis summary. 84% error rate!!

AFTER

  • Screenshot of response times and hit rates
  • Screenshot of summary of Analysis. 99.98% success rate!!

 

What a difference!!.. The server in fact stopped responding after the first test and had to be hard rebooted.  So how did I achieve it? By mostly copying the ideas from Ewan :). The final configuration for serving the web pages looks like this on the server end

Varnish (listens on TCP 80) –> Apache (listens on TCP 8080)

NOTE : All the configuration guides (as with the previous entries of the posts in this series) are specific to Ubuntu.

  1. Configure Apache to listen on port 8080
    1. Stop Apache [code] sudo service apache2 stop [/code]
    2. Edit the following files to change the default port from 80 to 8080
      1. /etc/apache2/ports.conf
        1. Change [code]NameVirtualHost *:80
          Listen 80
          [/code]
        2. to [code]NameVirtualHost *:8080
          Listen 8080
          [/code]
      2. /etc/apache2/sites-available/default.conf (NOTE: This is the default sample site that comes with the package. You can create a new one for your site.  If you do so, you need to edit your site specific conf file)
        1. Change [code] <VirtualHost *:80> [/code]
        2. To [code]<VirtualHost *:8080> [/code]
    3. Restart apache and ensure that it is listening on port 8080 by using this trick.
  2. Install Varnish and configure it to listen on port 80
    1. Add the Varnish repository to the system and install the package[code]sudo curl http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add –
      sudo echo "deb http://repo.varnish-cache.org/ubuntu/ lucid varnish-3.0" >> /etc/apt/sources.list
      sudo apt-get update
      sudo apt-get install varnish
      [/code]
    2. Configure Varnish to listen on port 80 and use 64Mb of RAM for caching. (NOTE: Varnish uses port 8080 to get to the backend, in this case Apache, by default. So there is no need to configure it specifically).
      1. Edit the file /etc/default/varnish
        1. Change [code]DAEMON_OPTS="-a :6081 \
          -T localhost:6082 \
          -f /etc/varnish/default.vcl \
          -S /etc/varnish/secret \
          -s malloc,256m"
          [/code]
        2. To [code] DAEMON_OPTS="-a :80 \
          -T localhost:6082 \
          -f /etc/varnish/default.vcl \
          -S /etc/varnish/secret \
          -s malloc,64m"
          [/code]
    3. Restart Varnish [code]sudo service varnish restart[/code]

      and you are ready to rock and roll.

There are some issues with this setup in terms of logging. Unlike your typical web server logs, where every request is logged, I noticed that not all the requests were being logged. I guess, that is because varnish is serving the content from cache. I have to figure out how to get that working. But that is for another post :).

HOW TO : Perform OCR on PDF files for free

I had to convert a scanned PDF file into an editable document recently. You can do this using OCR and there is a ton of software out there, that does this. There are even web based services that do this. But each of them had limitations (either had to buy the software or limit in the number of pages that can be scanned). I didn’t want to buy the license, since this is not something I would be doing regularly and the document I had to convert was 61 pages, so none of the online services allowed me to do it. I remembered reading that Google Docs, added this (OCR) capability a while ago and since I have a Google Apps account, I decided to give it a try.

Google also has a limit of 2 pages per OCR conversion. So after some brainstorming, I came up with this quick hack to use Google Docs for converting large PDF files into editable content.

  1. Split the PDF file into two page documents using PDFsam (Open Source PDF Split and Merge Tool).
  2. Log into your Google Docs interface at http://docs.google.com . All you need is a Google Account to use this feature
  3. Create a folder (collection) to organize your files. This is not required, but it will make searching for the files a lot easier
  4. Check the settings to convert PDF files to editable
  5. Upload the PDF files you created in step 1.
  6. As you upload the files, Google creates an editable document with the text from the PDF files. You can then create a new document and copy/paste the content from all the smaller files.

I think someone with more programming chops than me can improve this by using the Google API to do the copy/paste from the smaller docs into the final document :).