CA BD NY
  • Categories

  • Recent Posts

  • RSS MySQL Hacker

  • RSS Apache Hacker

  • RSS MiniCTO

  • Meta

  • Tuning tmpfs filesystem (/dev/shm) for CentOS

    Published November 5th, 2008

    Problem Statement

    By default, CentOS installer creates a very large tmpfs (/dev/shm) filesystem. In fact, it is likely that if you have 4GB of RAM, the default tmpfs filesystem will take approximately 2GB.

    Changing your default tmpfs (/dev/shm) settings

    Run df -h and you will the default /dev/shm size. Here is a sample output of this command:

    Filesystem            Size  Used Avail Use% Mounted on
    /dev/sda1             4.0G  567M  3.2G  15% /
    none                  512M     0  512M   0% /dev/shm
    /dev/sda2              20G  5.6G   14G  30% /usr
    /dev/sda4              28G   20G  7.1G  74% /var

    In this sample output, the /dev/shm is set to 512MB. If you do not have any application that uses this filesystem, you might be able to reduce this significantly. In fact, we run very large Web sites with hundreds of thousands of hits and have trimmed the default settings between 256MB to 512MB.

    So if you have 4GB of RAM and see a 2GB of tmpfs (dev/shm) filesystem, you can change it to a much smaller size such as 256MB as follows:

    • Locate the following line the /etc/fstab file:
      none                    /dev/shm                tmpfs   defaults      0 0
    • Change it the defaults to be size=[your size in megabyte]m. For example, to have a 256MB tmpfs filesystem, we have the following line in the /etc/fstab file:
      none                    /dev/shm                tmpfs   size=256m       0 0
    • Now reboot your system (sorry, if you simply umount /dev/shm and then mount it again using mount /dev/shm, it appears to not change the available memory — yup it puzzles us too)

    Creating a custom tmpfs storage

    Of course, tmpfs can be really cool if you want to have a very fast filesystem that can be emptied when you reboot. For example, if you do file-based sessions for you Web applications, you can put all your session data into a tmpfs filesystem. Or, you can put the most commonly requested files in a tmpfs filesystem to speed up your Web server.

    In such a case you are better off creating your own tmpfs filesystem. It is as simple as mounting a empty directory as a tmpfs filesystem using your free RAM. For example, to create a 1GB tmpfs filesystem on /mnt/ram do the following:

    • Make sure you have created an empty directory called /mnt/ram
    • Run: mount -o size=1G -t tmpfs tmpfs /mnt/ram
    • Now copy your files to /mnt/ram and use it as you do with any other filesystem
    • When you decide to take it down, just run: umount /mnt/ram

    Beware that whenever you take down (umount) a RAM filesystem such as tmpfs or reboot your system, the contents disappear immediately. So if you are setting up a Web server to have common files served from a RAM-based filesystem, you should have a shell script that is run from /etc/rc.local. For example, in /etc/rc.local add:

    # Load ram filesystem when server starts
    /etc/load_ram.sh

    Now create /etc/load_ram.sh as follows:

    #!/bin/sh
    
    # Size of your RAM disk (tmpfs)
    RAM_DISK_SIZE=1G
    MOUNT_POINT=/mnt/ram
    SOURCE_DIR=/var/data/web/common_files
    
    # Make sure the mount point exists
    mkdir -p $MOUNT_POINT;
    
    # Now create the tmp filesystem on mount point
    mount -o size=$RAM_DISK_SIZE -t tmpfs tmpfs $MOUNT_POINT
    
    # Copy the source files to the mounted tmpfs filesystem
    cp -r $SOURCE_DIR/*   $MOUNT_POINT
    

    A script like the above will create the tmpfs and copy the files that you want to serve. If you expect to update the files, make sure you have a cron job that copies the latest version from time to time back to the physical disk. Otherwise, you will have a lot of unhappy users and we all know that a’int good for anyone’s aorta. :)

    Get a Trackback link

    2 Comments

    1. rico_cebiche on March 9, 2009

      There is no need to shrink the size of /dev/shm, since the allocated memory is dynamic. If it is empty, it does not occupies RAM memory, that explains your puzzle when you reduce the default 50% RAM allocation and you did not see any memory use reduction. Also, glibc expects to find /dev/shm mounted.

    2. Gary on December 1, 2009

      To remount the shared memory device after changing your fstab; mount -o remount /dev/shm

    Leave a comment

    Comment Policy: First time comments are moderated. Please be patient.