Garbage collection occurs too frequently on high traffic sites, no column index
A bug in 2.2.2, submitted by nickdunn on 08 June 2011
Announcement
Symphony's issue tracker has been moved to Github.
Issues are displayed here for reference only and cannot be created or edited.
Browse
Closed#649: Garbage collection occurs too frequently on high traffic sites, no column index
Spoken directly to Nick about this. The site in question in a 2.1.1 build, so the majority of the issue has been solved in more recent versions.
The one thing I would like to take from this is adding the Session gc as a Configuration option, so that sites with a lot of traffic can adjust the value as necessary.
Added a new configuration setting, session_gc_divisor
in this commit
This issue is closed.
We've found that PHP's session garbage collection occurs very frequently on large sites. This is down to the value of
session.gc_divisor
that is set inclass.session.php
. On the site in question this was set to3
, meaning that the garbage collector runs in every 1 in 3 processes. I believe this was running a couple of times per second and peak times.2.2.2 seems to have a value of
10
hard coded into the file. Is there a chance this could be moved to a config value instead? PHP's default is100
, which is more like what we need for this site.Secondly it was noted that the sessions table did not have an index for the
session_data
column. Is there a reason why not, is it memory-intensive to maintain an index on a table of this potential size? I wonder if a FULLTEXT index on this might improve performance when running the REGEXP query against this column. A quick test with 15,000 rows yielded no performance difference with and without the index, but thought it worth mentioning.The full comment from the site's DBA:
==========
Today I've noticed problems with a high number of concurrent sessions, nearly all connected to [sitename] database. The majority of sessions are waiting on locked objects. In this case, I believe it's the entire table that's locked. Here's an excerpt from the MySQL processlist:
The problem is the "Delete" operation, e.g.:
It's doing a table scan each time it runs and locking the table for its duration, I believe. Hence any "select" against the sym_sessions table is queued on a lock wait for the duration.
There are perhaps three problems as I see it with this piece of SQL: