Skip site navigation (1) Skip section navigation (2)

Re: session servers in ram

From: Greg Spiegelberg <gspiegelberg(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: session servers in ram
Date: 2009-09-22 12:48:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, Sep 21, 2009 at 5:39 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:

> I'm looking at running session servers in ram.  All the data is
> throw-away data, so my plan is to have a copy of the empty db on the
> hard drive ready to go, and have a script that just copies it into ram
> and starts the db there.  We're currently IO write bound with
> fsync=off using a 15k5 seagate SAS drive, so I'm hoping that moving
> the db into /dev/shm will help quite a bit here.
> Does anybody any real world experience here or any words of sage
> advice before I go off and start testing this?
I assume you intend to this or some variation of it.
  mount -t tmpfs -o size=1G tmpfs /pgfast

tmpfs file systems, including /dev/shm, ***should not*** be counted on as
being RAM only.  File systems of this type in Linux, and at least Solaris
also, can be swap since the tmpfs type is derived from swap and swap =
memory + active swap partitions.

I would think that a ram disk or ramfs may be more what you're after.  Add
ramdisk_size=X, where X is the maximum size in kilobytes, to the kernel line
in your grub.conf file.  Unlike tmpfs, the ramdisk_size X parameter cannot
be more than the memory of your server.  When using a ramdisk the ext2 file
system would be best with all the fun noatime and like mount parameters.
This is good for a fast, volatile, fixed-size ramdisk.

OTOH, ramfs can be just as fast but with all the fun system-hanging features
like growing until all RAM is consumed.
  mount -t ramfs ramfs /pgfast

Pro ... it will always be as fast, or possibly a hair faster, than tmpfs.

Con ... it won't show up in a df output unlike tmpfs or ramdisk.  Use the
mount command with no parameters to look for it and be sure to unmount it
when you're done.

Pro/Con ... you can't specify the file system type like with ramdisk.

Pro... it will only take away from memory as space is used, i.e. if you have
500M of memory in use and mount the file system but do nothing else then
only 500M of memory is in use.  If you then copy a 100M file to it then 600M
of memory is in use.  Delete that 100M file and you're back to 500M of used

Pro/Con ... unlike other file systems, it will grow with the need...
unchecked.  It could attempt to consume all available memory pushing all
other processes out to swap and this is a bad, bad thing.

I'm sure there are other pro's & con's to ramfs.



In response to


pgsql-performance by date

Next:From: Grzegorz JaƛkiewiczDate: 2009-09-22 12:51:03
Subject: Re: query memory consumption
Previous:From: Alan McKayDate: 2009-09-22 12:46:04
Subject: Re: query memory consumption

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group