VPS /tmp partition and PHP session files

Hi all,

Having switched to a VPS one of the first things that happened was our /tmp partition maxed out with PHP session files. No big deal, just deleted the old ones, but of course this will continue to happen if PHP is not removing timed-out sessions itself. df tells me that a separate device, presumably just some other disk partition, I haven’t checked, is mounted on /tmp with a capacity of just 128M.

Right now I’ve got a cron job that runs every 15 mins and deletes any session file that has not been accessed for 60 minutes or more. This should keep on top of things.

So I guess I’m looking for some advice from others about managing the session files (or getting PHP to do it for me). It’s always something I was curious about - how the PHP interpreter knew when session files could be deleted, how it went about doing so, and why my servers (at home and in public) never ended up flooded with session files. But they didn’t, so my curiosity never got the better of me, I just figured that the issue had obviously also occurred to the PHP folks and that they had it managed.

Is it worth contacting support to ask if the /tmp partition can be any bigger (I guess I should check the mtab first)? Should I reconfigure php.ini to put my session files in a different place on my main storage instead of on the /tmp partition? Should I use database sessions instead of files-based sessions? Or is the problem simply that, because users don’t always log off, some sessions just never get destroyed so the brutal cron job is just a necessary evil?

Thanks in advance.

PHP is supposed to automatically clean up old sessions on its own. The heuristics it uses for doing so are kind of crazy (one out of every hundred PHP processes will check for sessions that haven’t been touched in a while and remove them); see http://us1.php.net/manual/en/session.configuration.php#ini.session.gc-probability for the gory details.

By default, /tmp on a VPS is mounted as a 128 MB RAM disk. If this is too small for you, let Support know and we can switch it to be stored on disk like the rest of your files; this’ll slow things down somewhat, but will give you a lot more room to work with.

Thanks, good to know. The cron job is working for the time being, but I’ve got it sending me usage stats for /tmp so if we get close to the red line I’ll contact support.

I figured PHP must be doing something like that as I’ve never heard of or noticed (or set up, for that matter, on any of my own machines) a daemon to take care of session maintenance. A daemon would likely be overkill, but randomly forcing a process to clean up after other processes seems a bit, well, basic - like the kind of approach I would have taken because I’m too lazy to think of anything better ;).

I guess on a shared server the probability pools over all the PHP processes, so that sessions get cleaned up more frequently. On our VPS, we’ve only our own PHP processes, so we get much less frequent gc. Or are PHP processes and sessions isolated on shared hosting in the same way as they are on a VPS - i.e. does a PHP process only clean up sessions set by the same (nix) user?

Does the per-directory php.ini magic work on VPS like it does on shared? Could I increase the gc probability that way? Or would I have to take over ownership of php on the VPS and maintain my own php.ini server-wide?

PHP session garbage collection is all per-user — users cannot delete files from /tmp which are owned by other users. If you are having issues with running out of space in /tmp, the approach you’ve taken (cleaning /tmp yourself with a separate script) is preferable to tweaking PHP’s settings.

Note that, if you’re managing to fill 128 MB with session files, either you’ve got a whole heck of a lot of sessions, or they’re pretty big. If the latter is the case, you may want to look into slimming them down (e.g, by storing less data in the session).