Re: session servers in ram

On Tue, Sep 22, 2009 at 12:01 PM, Ron Mayer
<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Alan Hodgson wrote:
>> On Monday 21 September 2009, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
>>> I'm looking at running session servers in ram.
>>
>> Use memcached for session data.
>
> IMHO postgres is more appropriate for some types of session data.
>
> One of the apps I work on involves session data that consists of
> geospatial data which we store and index in postgres/postgis.
>
> Scott Marlowe wrote:
>> I'm looking at running session servers in ram.
>>  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.
>
> "a 15k5 seagate SAS drive"
>
> Is this implying that you have "a" == one session server?  I
> bet that it'd be cheaper to throw a bunch of cheap boxes
> in there and make a pool of session servers rather than one
> fast one.   When a new session is created, your application
> code can then pick the least loaded session server and put
> the session-server-number in a cookie.

We already have two using modulus load balancing, and each is handling
up to 100,000 sessons each, and an average session object of 10k to
20k. I'm just looking at how to keep from throwing more cheap boxes
at it, or having to put more drives in them. We're mostly IO bound on
these machines, even with 100 checkpoint segments and a 30 minute
checkpoint timeout and a low completion target to reduce checkpointing
even more.

Even with a move to a ramdisk, I'm guessing with our increasing load
we're gonna need to double our session servers eventually.

As for memcached (mentioned in another post), I'm not sure if it's the
right fit for this or not. We already use it to cache app data and it
works well enough, so it's worth testing for this as well I guess.

Thanks for all the input from everybody, I'll let you know how it works out.