Still, big session problem

Rails Deployment
1

I am still having a rather bad sesssion problem on my production
server.

/tmp is getting loaded with ruby_sess files and eventually (probably
takes 2 weeks) crashes out my application. Can someone point me to an
article that better explains how to deal with file based sessions? Or
should I just be running a cron job?

2

I would highly recommend switching to ActiveRecordStore for keeping
track of your sessions. You’ll still have to periodically delete
sessions, but it’s easy to do, and much more efficient (and scalable)
than file-based sessions.

http://wiki.rubyonrails.com/rails/pages/HowtoChangeSessionStore
3

Depending on the database, ActiveRecordStore is a bad idea. Especially
when using a database that does not support row level locking (like
MyISAM tables in MySQL-databases), constant concurrent reads and writes
are a problem. In my opinion, the place for these large, small and
potentially unstructures datasets is eighter the file system or memory.
(thus, memcached or pstore)

If you do not have any problems with session performance, it might be
wise to just set up a hourly cronjob that sweeps all files older than 15
minutes (or whatever your session length is set to) inside your
temp-directory.

4

Mike,

Just switched over. Thank you for that suggestion, it was so easy!

I should clear the table data every now and then right?

5

Hopefully this sparks a debate then because having run into my file
based session problem, I’d like to know what are the cons of
ActiveRecordStore. All I know is, 50,000 ruby_sess files taking down
my app aren’t good.

On Apr 16, 1:48 pm, Florian G. <ruby-forum-incom…@andreas-

6

jcontonio wrote:

Hopefully this sparks a debate then because having run into my file
based session problem, I’d like to know what are the cons of
ActiveRecordStore. All I know is, 50,000 ruby_sess files taking down
my app aren’t good.

On Apr 16, 1:48 pm, Florian G. <ruby-forum-incom…@andreas-

Thats a problem that could also be solved by dividing sessions in
multiple folders (take numbers and search your folders). The main
Problem of pstore is that it spams one folder - a scenario that files
systems are not build for. They may allow it, but they can’t handle it
very well. A more intelligent storage could cope with that. BTW, thats a
similar idea as in partitioning tables for better write performance on
tables with table locking. If your system can’t handle your set,
partition it. (or clean up regularily, as i suggested above)

As for cons against DB based store: as i mentioned before, it’s
performance is not database-agnostic, while pstore and memcached
performance pretty much behaves the same on most system. It suffers from
many concurrent hits on your database while filesystems are better
designed to handle such tasks. Another thought is that volatile data
like the session can be kept memcached, as in case of something really
nasty happening, your sessions will likely be invalid anyway.

On the other hand: these are thoughts are for final optimization. As you
needed a quick fix, ActiveRecordStore is perhaps not that bad ;).

7

Hi,

The Reiser 3 file system was built to handle millions of files in a
directory effortlessly. And, unlike many other file systems, it is
space efficient with tiny files like this. If you’re using Linux, then
this is a good solution for your session storage. (though perhaps more
difficult to retroactively fit :).

Ext3 now has directory hashing too, but I don’t think it’s enabled by
default, and I’ve not tested it’s performance.

Looking at the FileStore code though (from actionpark 1.13.3, it cannot
be trusted to atomically update fragments in a multi-process setup
(though it seems to be thread safe). This means you could conceivably
read a fragment as another process is writing to it, and get a broken
session object or corrupted cache fragment.

If you’re using an OS with an atomic rename system call (like Linux, and
probably any UNIX) then you could tweak the FileStore code to avoid the
race. If not, and you still want to use FileStore, then I’d recommend
using one FileStore object over drb.

If you store sessions in memcached, bear in mind that when its ram pool
fills it will automatically expire entries that have been used the least
recently.

This might be more detail than is necessary for the original poster, but
maybe it’s useful to someone.

John.

On Mon, 2007-04-16 at 20:24 +0200, Florian G. wrote:

Thats a problem that could also be solved by dividing sessions in
multiple folders (take numbers and search your folders). The main
Problem of pstore is that it spams one folder - a scenario that files
systems are not build for.

As for cons against DB based store: as i mentioned before, it’s
performance is not database-agnostic, while pstore and memcached

–
http://johnleach.co.uk

http://johnleach.co.uk

8

On 4/16/07, Rob S. [email protected] wrote:

Just run a cron job.

Here’s one way:
http://www.realityforge.org/articles/2006/03/01/removing-stale-rails-sessions

  • rob

Actually that was for AR sessions - here’s a method for file sessions:

  • Rob
9

On 4/16/07, jcontonio [email protected] wrote:

Rob,

Thanks for the help. Any idea how this works on a FreeBSD system? The
find command is kinda different here.

A for the link on that page to the Ruby way of doing things, it’s
rather confusing where to put that.

Sorry, I don’t know with FreeBSD.

  • Rob
10

Rails 2.0 features a hashed cookie-based session store by default, which
is the best performer and is highly recommended as long as you keep your
session size below 4 KB or so.

–
Roderick van Domburg
http://www.nedforce.com

11

Rob,

Thanks for the help. Any idea how this works on a FreeBSD system? The
find command is kinda different here.

A for the link on that page to the Ruby way of doing things, it’s
rather confusing where to put that.