Re: session servers in ram - Mailing list pgsql-performance

Hello

this is maybe off topic. Do you know memcached? We use it without
postgresql six or seven months for short-live data with big success.

regards
Pavel Stehule

2009/9/22 Greg Spiegelberg <gspiegelberg@gmail.com>:
> On Mon, Sep 21, 2009 at 5:39 PM, Scott Marlowe <scott.marlowe@gmail.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
> memory.
>
> 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.
>
> HTH.
>
> Greg
>