From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Greg Spiegelberg <gspiegelberg(at)gmail(dot)com> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: session servers in ram |
Date: | 2009-09-22 13:05:43 |
Message-ID: | 162867790909220605o76aad151y73609ebc6028a2d0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com>:
> 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
> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2009-09-22 13:16:44 | Re: session servers in ram |
Previous Message | Grzegorz Jaśkiewicz | 2009-09-22 12:51:03 | Re: query memory consumption |