4

Ok so the title is pretty self explanatory. There's thousands of rows in the session table. I see that the Persistent Login module is enabled. I don't know if this affects how the sessions are stored. Also, I note that 100+ users are quoted as being visitors at any one time, which seems very excessive for the user base and niche content of this site.

Please can someone advise the best course of action here? I assume I can truncate this table locally, but what's the long term action plan look like?

  • Do you have cron running? – mpdonadio Oct 1 '11 at 20:09
  • Cron was not running, because of a code problem in a contrib module. Very annoying. Fixed. Ran cron, but the sessions table was still very large. Can only assume the session time is enormous and needs changing in the settings.php. – NikLP Oct 3 '11 at 16:14
  • Persistent login module requests that session lifetime be set to 0, but it is of course 200000. What I don't know is whether to alter this or remove the module completely, or indeed how this module affects site speed or stored sessions - would it work in parallel with the drupal.org/project/no_anon module to additionally speed things up a bit for anon? – NikLP Oct 3 '11 at 16:16
  • Have you profiled things and identified that you have a problem, or do you just think you have a problem because of your row count? Databases store lots of data; that's their job. Only start worrying about things when you have to. If you have a high volume site, then optimize the web server (httpd and mysqld if that is what you are running) for normal behavior, then start worrying about things like sessions. – mpdonadio Oct 3 '11 at 20:53
  • I was initially concerned about the sessions mostly because a) the site was running very slowly (this is almost certainly associated with a poorly spec'ed server, with only 1GB of RAM) and b) because admin_menu was reporting 100-150 guests online at one time, which is either incorrect (possibly due to persistent_login, I don't know) or causing a performance problem that could have been potentially associated with sessions - I'm reasonably ignorant on the effect of sessions in this regard, hence the initial question. – NikLP Oct 4 '11 at 8:38
2

The long term action is to limit session lifetime. Look for the following line in your settings.php:

ini_set('session.gc_maxlifetime',   200000);

This parameter sets session life time, after which session is marked as garbage and will be deleted by garbage collector. Average session life time (not on drupal sites) is much less than 200000 seconds - something between 15 minutes and half an hour (900-1800). So, if you don't need long sessions, you can reduce ini_set value and thus get less sessions stored in the sessions table

1

Likely, the thousands of rows are caused by anonymous sessions. Look at the sessions table, and see how many rows have uid==0 vs uid!=0

SELECT COUNT(sid)
FROM sessions
WHERE uid = 0

SELECT COUNT(sid)
FROM sessions
WHERE uid != 0

Drupal 6 creates sessions for anonymous users during bootstrap.

Pressflow 6 and Drupal 7 only create sessions when you actually save something to $_SESSION.

There is a module, No Anonymous Sessions, that does what the its name says, but it can break some features and non-core modules.

That said, I would only worry if you are seeing (and measuring) actual performance impacts.

As long as your cron is running, the table should not grow without bounds. It you look at the table sizes, it is probably much smaller than the cache tables, search index, and watchdog tables.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.