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
details
- 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.
Comments
Comment #1
kbahey CreditAttribution: kbahey commentedI too am bothered by the fact that we delegate this to PHP, which is unpredictable.
I too, use Ubuntu.
In /etc/php5/apache2/php.ini, you will find this commented out:
;session.gc_probability = 0
If you set that to 1, it will probably do the trick, but when you upgrade, you have to remember to redo the chanage.
Regardless, I think leaving sessions around, specially for anonymous is too risky, given all the possible configurations out there.
I proposed a fix for this, whereby we use our predictable cron, and control it ourselves. You can see it in #72856, but it was rejected.
I could reroll the patch again, if it has a chance of being accepted.
Otherwise I will create a contrib module (or maybe a mini module) that just does that.
Comment #2
catchhttp://drupal.org/node/72856
Comment #3
Samat Jain CreditAttribution: Samat Jain commentedDebian reports this "fixed;" Debian's php.ini now includes a better warning. See Debian bug 388808.
With Debian's fix, Drupal still needs to handle this.