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.
2009/9/22 Greg Spiegelberg <gspiegelberg(at)gmail(dot)com>:
> On Mon, Sep 21, 2009 at 5:39 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
>> 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: Aidan Van Dyk||Date: 2009-09-22 13:16:44|
|Subject: Re: session servers in ram|
|Previous:||From: Grzegorz Jaśkiewicz||Date: 2009-09-22 12:51:03|
|Subject: Re: query memory consumption|