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?

Improve this question
7
  • Do you have cron running?
    – mpdonadio ♦
    Oct 1, 2011 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, 2011 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, 2011 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, 2011 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, 2011 at 8:38

2 Answers 2

Reset to default
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

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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