How should I handle session files that become too numerous?

Apart from deleting session files with find using a custom modification time as mentioned by others, you also can:

• Save the sessions in your database. Of course this will put load on your database and it's not the fastest way, but you can handle way more sessions that way and you can share sessions between multiple frontend servers. You can change the setting in app/etc/local.xml by switching

  <session_save><![CDATA[files]]></session_save>
  

  to

  <session_save><![CDATA[db]]></session_save>
  

• Use memcached as your session storage. Magento also supports this by default. Have a look at app/etc/local.xml.additional for the configuration. I never used it in production but have heard that this may be a little bit tricky.

• Handle the sessions in Redis using Colin Mollenhours brilliant extension Cm_RedisSession. Setting up Redis shouldn't take up too long, can also be used for caching (see Cm_Cache_Backend_Redis) and combines a RAM cache with persistence on disk (in opposition to memcached, RAM disks or the like) which is always in case your server is crashing.

With file based sessions, they will be auto-pruned by the PHP session clean-up cron – so the files are likely to be deleted within ~7200 seconds of creation. So even on a busy site (30k uniques per day), there usually only around 4,000 session files in ./var/session – which is nothing even for a low-end Linux server.

However, the clean-up actually relies on the cron working - which doesn't normally look in the ./var/session directory of Magento. So you should set up a new system cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1

The default clean up period for sessions is 7200 seconds, which should be more than adequate, although you can change the above to suit.

With Memcache sessions, TCP/IP is the only overhead – which for a single-server deployment, would make it slower than file based. So then, you would use a unix socket instead, which removes that overhead and gives better security. But even still, your customer sessions will be truncated/limited as to the amount of RAM you can allocate. The average Magento session is 4Kb – so you’ll be able to support 256 active sessions, per MB you allocate. So be sure to set an appropriate limit to avoid customers randomly losing cart/session. And also bear in mind, a Memcache daemon restart will wipe out all existing sessions (BAD!).

With Redis (not native, but available via an extension), you get a similar level of support as Memcache, but with the added benefits of persistence (should you wish to use it). With the Cm_Redis extension, you'll also be able to take advantage of session compression. We've found this extension works very well on both CE and EE deployments.

The with DB, the default prune expiration setting is a mighty 1 week, so with the above store size as an example (30k uniques per day), you’ll be looking at a DB table size for core_cache_session of around 7GB – which will grind your store to a complete halt, for almost every session based operation.

From experience of hosting both large (230k unique visitors per day) and small (<1k unique visitors per day) stores, our recommendation is:

Single-server deployment - files

Multi-server deployment - Redis (using a separate database from the main Magento cache)

I wrote some really thorough replies here http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

I've asked a related question some time ago:

https://stackoverflow.com/questions/7828975/php-garbage-collection-clarification

What I never found out (I left that job for a new one, and the original problem became someone else's) is if Magento's sessions will honor these settings, or if they implement their session handling using Zend (and presumably some sort of zend.ini config file).

The php settings to look at:

session.gc_maxlifetime session.gc_probability session.gc_divisor

http://php.net/manual/en/session.configuration.php#ini.session.gc-probability