Every week or couple weeks, my application goes haywire, and in my production.log I get, No space left on device - /tmp/ruby_sess.938af5ba9b9a02ed Visiting the site, it looks like it refreshes every second. Any ideas? I am not running out of physical HD space, so this is confusing.
on 2007-03-26 21:23
on 2007-03-26 21:31
jcontonio wrote, circa 2007-03-26 1:23 PM: > Every week or couple weeks, my application goes haywire, and in my > production.log I get, > > No space left on device - /tmp/ruby_sess.938af5ba9b9a02ed > > Visiting the site, it looks like it refreshes every second. > > Any ideas? I am not running out of physical HD space, so this is > confusing. I'm assuming this is on Linux, and that you're running with the ext3 file system, but feel free to correct me if I'm wrong. It's possible that you've run out of inodes -- using the file system for session storage results in the creation of mind-boggling numbers of files, and that can exhaust the file systems inode resources quickly. Check the output of: df -i /tmp and see what it says under "IFree". Hope that helps, Jeff
on 2007-03-27 00:49
Actually FreeBSD but you're exactly right. What's the best way to solve this?
on 2007-03-27 01:11
jcontonio wrote, circa 2007-03-26 4:49 PM: > Actually FreeBSD but you're exactly right. What's the best way to > solve this? My FreeBSD knowledge isn't particularly keen so I probably can't be of much help, but it's entirely possible that you might not be able to adjust the inode count of a UFS volume without reformatting the volume or slice. You can't with ext3, either, as far as I'm aware. If you do have the luxury of being able to re-create the file system -- such as if /tmp is a file system all its own and you can move the data off of it, unmount it, reformat it, remount it, and move the data back all in a relatively short period of time with no services running -- then you could use the -i and -f options for /bin/newfs. Doing something like -f 1024 -i 1024 should give you a reasonably usable file system for doing file-system-based session store, but that's an awful lot of trouble to go to for what's basically provided as a lowest-common-denominator way to store session data My recommendation -- for this reason and for many, many others -- would be to switch to the ActiveRecord session store. Ideally, if you're using MySQL, use a MyISAM table (rather than InnoDB, which is a more advanced table format with transactions and other such features you don't need for an AR session store table). I suspect I'm not alone in recommending this, either, but if there are reasons you can't do so with your application I'd be interested in hearing them as there are other session store options available which might better meet your needs. Thanks, Jeff
on 2007-03-27 02:04
Depends on the filesystem - for ext2/3, the number of inodes are fixed at fs creation time, while some (like reiserfs, I believe) don't have a fixed number of inodes. Not a BSD guy, but the same issues apply. Either way, it would require the filesystem be reformatted. Of course, you could just delete some files =) You are deleting old session files, right?
on 2007-03-27 03:36
Two recommendations: 1. Do not use file system for sessions storage in production. It's VERY slow and leads to problem like you outline. 2. Once you change session storage to ActiveRecord, be sure to clean up stale sessions on a regular basis. Alex Verkhovsky