Drupal Association members fund grants that make connections all over the world.
The issue reported last year http://drupal.org/node/72856 was dropped because folk were unable to replicate it, and called it misconfiguration.
However it's a very real problem, that I've now encountered on both Debian Etch and Ubuntu.
It's documented right out there in the distributed php.ini and on the PHP Website
I found myself fighting with all sorts of optimizations trying to combat :
2GB in the sessions table
... and going up all the time.
sess_gc() never, ever, gets triggered on a Debian system
No matter what gc_maxlifetime is set to.
Old sessions never die. I actually thought it was cute that I could come back to my dev sites weeks later and it'd recognise me, but not when our released site got over 100,000 anonymous users in a week. (plus, the application saves a couple of KB of serialized data in the session too)
Simply : Debian only clears dead session data if you are using the default 'files' method.
... if you write your own session handlers you'll need to explicitly call your _gc function yourself
So, I'm currently trying the solution from php.net which triggers garbage collection on sess_close. I'm imagining that a better fix would be a cron hook for session
This was also accurately identified (but not fixed even earlier).
I am really happy that I've finally located our issue, and that performance is once again performing - after spending absolute days benchmarking and optimising and going slightly mad. This is apparently a debian only issue, but I need a suggestion on the very best way to work around it.
; This is disabled in the Debian packages, due to the strict permissions ; on /var/lib/php5. Instead of setting this here, see the cronjob at ; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below ;session.gc_probability = 0 session.gc_divisor = 100 ; After this number of seconds, stored data will be seen as 'garbage' and ; cleaned up by the garbage collection process. session.gc_maxlifetime = 1440
- On a Current Debian system [Linux version 2.6.15-28-386 (Ubuntu 4.0.3-1ubuntu5)| Apache/2.0.55 (Ubuntu) PHP/5.1.2]
- Place a debug notice in session.inc function sess_gc()
watchdog('session','session garbage collection actually happened!');
- Set session.gc_maxlifetime to anything, in settings.conf which should over-ride php.ini.
print t('Inactive user sessions will be dropped after %duration ', array('%duration' => ini_get("session.gc_maxlifetime"). ' seconds, or ' . format_interval( ini_get("session.gc_maxlifetime") ) ) )
- Start multiple sessions, anon sessions, clear cookies
- Wait that long. wait longer.
- Run cron, Run a spider, log in, log out, clear db cache, anything to bump it along!
- Search logs. No message
- View timestamps still in sessions table
SELECT count(*) FROM sessions; SELECT uid, hostname, DATE_FORMAT(FROM_UNIXTIME(timestamp), '%D %M %h:%i:%s ') as time, cache FROM sessions ORDER BY timestamp ;
Old dates there.
... old sessions are never dropped.