Symphony.

It seems that there have been changes to /lib/core/class.session.php in one of the latest releases which do not work as intended. Once again (like here) I experience problems with the sessions table in the database not being cleaned up – it is growing and growing….

I have reached 98.000 sessions in the sessions table. Any ideas what might be wrong here? It’s a website which has been updated from Symphony 2.0.3 to 2.0.6.

Still looking into this one. It appears as though new sessions are being created rather than reusing the existing ones. I really hate debugging session problems.

I have reached 117000 sessions now. Anything to worry about?

:-)

It looks that Session::gc function isn’t executed anywhere.

I can confirm that I’ve also got a 2.0.6 install whose session table grows unabated and then, from time to time, crashes. I’ve taken to emptying it every few weeks just to be safe.

At what point should old sessions be destroyed? What triggers this? As rainerborene points out, neither the destroy() nor gc() methods are ever called anywhere else in the core.

Here’s a question: are sessions created for each visitor, or just for people logging-in to the backend?

neither the destroy() nor gc() methods are ever called anywhere else in the core

Duh, because they are set up to trigger as the session_set_save_handler callbacks.

So when a session is destroyed the destroy and dc methods are called and the expired sessions removed (comparing to the TWO_WEEKS lifetime). Question: when we say sym_sessions is never emptied, are we actually seeing sessions representing traffic over the last two weeks?

If a website receives 100 visits a day, 100 * 7 (days) * 2 (weeks) = 1400 rows you will see in sym_sessions.

So perhaps we are seeing the rolling view of two weeks’ worth, and not sessions for all of time?

Perhaps as a fallback the destroy/gc methods need to be executed when a new session is created as well. So each new session triggers a purge of the old sessions. A shame though, since the current implementation is clean.

Hmm, that said I checked an older site (2.0.1) and there are about 2 million sessions in the table.

are we actually seeing sessions representing traffic over the last two weeks?

I converted the UNIX time to human readable time using the following shell command (which won’t work on OS X, so you better try it on a webserver or comparable -NIX machine):

date -d @1264458524

Actually on the website in question the oldest entry (of around 122.000 entries) is exactly two weeks old. So you might be right, Nick.

Still I don’t understand the overall number of sessions. The website in question doesn’t have more than some hundred unique visitors a day. How long does a visitor use the same session? Could it be that all the rest are sessions for crawling robots???

Hmm, that said I checked an older site (2.0.1) and there are about 2 million sessions in the table.

There have definitely been problems with the session table not being cleaned up in those Symphony versions. So take a look at Alistair’s fix – it might help!

Cool, that’s the same as my suggestion:

Perhaps as a fallback the destroy/gc methods need to be executed when a new session is created as well. So each new session triggers a purge of the old sessions

Should go into the core?

Okay, I think we might have found the problem. The default probability of PHP calling the garbage collection function is approx 1% across all PHP script executions across the entire server (not just when Symphony fires).

2.0.8 introduces the following to the Session class:

ini_set('session.gc_probability', '1');
ini_set('session.gc_divisor', '3');

This will increase the likely hood that the GC function will get called, during the execution of Symphony’s code, 33% of the time.

Also added code to the GC function which will make a note in the log. Anyone that has experienced this problem, apply the patch, keep and eye on your log and let us know if it has worked.

Fingers crossed this finally solves the problem.

http://github.com/symphony/symphony-2/commit/7a4176e2a8294b2b12c3299106fdfee6849b2bbb

Alistair, your patch doesn’t seem to work on 2.0.7. I get:

Access to undeclared static property: Symphony::$Log in /Users/me/Sites/dev/www.example.com/symphony/lib/core/class.session.php on line 140

[EDIT]: I only get this error message every few page loads.

I should have mentioned, the fix requires 2.0.8RC1 or later code. You could also comment out line 140.

Alistair, can you explain the overall number of sessions I experienced? Will it be reduced by the patch? (None of these sessions is older than two weeks.)

As of 2.0.8RC1, this is no longer an issue for me.

Alistair, can you explain the overall number of sessions I experienced? Will it be reduced by the patch? (None of these sessions is older than two weeks.)

I think this might be a separate issue, and the session class implementation is a pretty standard one. Perhaps there is a deeper underlying problem in PHP which causes new sessions ID’s to be issued, leaving an orphaned session row.