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?
on 2007-04-16 15:22
on 2007-04-16 18:45
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/HowtoChang...
on 2007-04-16 19:48
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.
on 2007-04-16 20:00
Mike, Just switched over. Thank you for that suggestion, it was so easy! I should clear the table data every now and then right?
on 2007-04-16 20:03
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 Gilcher <ruby-forum-incom...@andreas-
on 2007-04-16 20:24
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 Gilcher <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 ;).
on 2007-04-18 16:13
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 Gilcher 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
on 2007-09-25 23:03
On 4/16/07, jcontonio <email@example.com> 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
on 2007-09-25 23:05
On 4/16/07, Rob Sanheim <firstname.lastname@example.org> wrote: > Just run a cron job. > > Here's one way: > http://www.realityforge.org/articles/2006/03/01/re... > > - rob Actually that was for AR sessions - here's a method for file sessions: http://www.missiondata.com/blog/?p=58 - Rob
on 2007-09-25 23:05
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.