IMPORTANT: Large sessions table on Debian/Ubuntu Linux hosted forum?

Started by Daniel15, December 16, 2007, 08:00:14 PM

Previous topic - Next topic

Daniel15

Hi everyone,
If you're using Debian Linux to host a SMF forum and are using database-driven sessions, I'd suggest to apply the below change immediately. Due to how Debian manages sessions, if you're using database-driven sessions, the garbage collection (deletion of old sessions) is not running and your smf_sessions table will grow to a massive size (mine got to 250,000 rows, consuming over 200 MB of space.)

In Load.php, find:

if (!empty($modSettings['databaseSession_enable']) && @version_compare(PHP_VERSION, '4.2.0') != -1)
session_set_save_handler('sessionOpen', 'sessionClose', 'sessionRead', 'sessionWrite', 'sessionDestroy', 'sessionGC');
elseif (@ini_get('session.gc_maxlifetime') <= 1440 && !empty($modSettings['databaseSession_lifetime']))


Replace with:

if (!empty($modSettings['databaseSession_enable']) && @version_compare(PHP_VERSION, '4.2.0') != -1)
{
session_set_save_handler('sessionOpen', 'sessionClose', 'sessionRead', 'sessionWrite', 'sessionDestroy', 'sessionGC');
ini_set('session.gc_probability', '1');
}
elseif (@ini_get('session.gc_maxlifetime') <= 1440 && !empty($modSettings['databaseSession_lifetime']))


Assuming that you're reading this, your sessions table is probably already rather full. The best  thing is to empty it via a "TRUNCATE" (you may do so in phpMyAdmin, or TRUNCATE TABLE smf_sessions via MySQL).



Technical explanation:
Because of Debian's security, /var/lib/php5 (the directory sessions are stored in) is unreadable by root users (essentially, CHMODded to 0733). Files have the permissions set normally, so PHP can still write files to the directory and read the files (providing it knows the file name, which would be the session ID), but no users can get a directory listing of the /var/lib/php5 directory. This is for additional security, I suppose - Trying to get a directory listing of the directory by whatever means will just give "Access Denied" messages, preventing local/hosted users from getting session data unless they know the session ID (on some other systems, getting a listing of /tmp/ will show all sessions, and then other users may steal these sessions).

Because of this, PHP's garbage collection won't work (because it can't get a list of all the files). Instead, Debian's PHP package comes with a cleanup cron job that runs every 30 minutes or so (I think) to remove the old files. This works fine for file-based sessions, but with database-based sessions, garbage collection needs to be implemented manually (or, like I've done here, the in-built PHP garbage collection needs to be turned on again).

Hope this helps :)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

青山 素子

As this is a very good recommendation, I will sticky this. (If the other managers feel this isn't needed, please remove this line and unsticky. Thanks.)

Considering Ubuntu and its family are based on Debian, if you are running a server on one of those, it might be worthwhile to check if this applies to you as well.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Stüldt Håjt

Thanks for the tip.

I haven't been looking in my database for some time now.

1 247 304 rows, 1,3 Gb size.

I'll truncate when there are less people online because it might take a while.

I'll keep you updated how things go.

Chriss Cohn

#3
Very nice tip! I hope this is php-version independent... i currently use PHP 5.0.25 with suoshin-package...
Also i think in the next version this should be included....

Regards, Christian


Stüldt Håjt

Done, everything went fine. No I have 1.6gb smaller database. :)

Hopefully your Load.php hack works!

Daniel15

QuoteVery nice tip! I hope this is php-version independent... i currently use PHP 5.0.25 with suoshin-package...
There is no PHP 5.0.25... I think you mean PHP 5.2.5? :)
It is version independant, I'm using the PHP packages from dotdeb.org, but this also applies for the standard Debian PHP packages.

QuoteHopefully your Load.php hack works!
I didn't test it extensively, but it should work :)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

shadow82x

Ahh I was wondering why my sessions table was 30mb in 1 week after clearing the table... Thanks. :)

I suppose this will do the same trick for SMF2.0b1?
Colin B
Former Spammer, Customize, & Support Team Member

Owdy

Thanks for this tip. No wonder my sessions table was so huge :D Dou you put this patch to 1.1.5?
Former Lead Support Specialist

Tarvitsetko apua SMF foorumisi kanssa? Otan työtehtäviä vastaan, lue:http://www.simplemachines.org/community/index.php?topic=375918.0

Panzer-


Something like that

Quote from: Last.Karrde on January 22, 2008, 08:19:06 PM
A Cronjob could be set up to empty it couldnt it?

That's like putting air in you tire every day instead of fixing the leak.

calamine

Quote from: Daniel15 on December 16, 2007, 08:00:14 PM
Hi everyone,
If you're using Debian Linux to host a SMF forum and are using database-driven sessions, I'd suggest to apply the below change immediately.

my hosts uses Debian Linux ver-4.0
regarding this data base driven - how to know whether i am using this feature or not..

i am new to smf.. but i am interested to learn

could u pls help me..
using smf 1.14 + tiny portal 0..9.8

Panzer-


Daniel15

QuoteI suppose this will do the same trick for SMF2.0b1?
It should... I've been clearing mine manually, haven't had time to implement this yet. :P

QuoteA Cronjob could be set up to empty it couldnt it?
That should also work :)
Although, I think using the in-built garbage collection is better. Basically, it runs the sessionGC() function in Load.php to delete old sessions:

function sessionGC($max_lifetime)
{
global $db_prefix, $modSettings;

// Just set to the default or lower?  Ignore it for a higher value. (hopefully)
if (!empty($modSettings['databaseSession_lifetime']) && ($max_lifetime <= 1440 || $modSettings['databaseSession_lifetime'] > $max_lifetime))
$max_lifetime = max($modSettings['databaseSession_lifetime'], 60);

// Clean up ;).
return db_query("
DELETE FROM {$db_prefix}sessions
WHERE last_update < " . (time() - $max_lifetime), __FILE__, __LINE__);
}


Quoteregarding this data base driven - how to know whether i am using this feature or not..
Admin panel → Server Settings → Feature Configuration → Use database driven sessions. If that's ticked, it's using database-driven sessions.
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

viulian

Whoa, exactly my issue!!

I'm on Ubuntu 6.06 and began researching because my sessions table reached 250Mb..

Thank you Daniel.

PS: lucky for me I was patient enough. Was searching for the 'sessions table' using the forum's search function, and this post was the LAST one. Why aren't sticky posts displayed first in the search result ?

Brettflan

Thanks for the info, I've got a fairly large Debian hosted forum which currently has a 2.8 GB sessions table, even after having truncated it about a year ago. :P
Looks like I'll be truncating the table again for sure and everybody will have to log back in, oh well. At least after this change the sessions table should remain a manageable size.

Again, many thanks.

Daniel15

Glad I could help :)

QuotePS: lucky for me I was patient enough. Was searching for the 'sessions table' using the forum's search function, and this post was the LAST one. Why aren't sticky posts displayed first in the search result ?
Hmmm... No idea why they're not first.  Anyways, I modified the subject so it's hopefully more relevant :)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

viulian

I wanted to say that the session table will eventually cleared itself, I didn't have to truncate it. So let it be a couple of days, and probably those sessions will start to expire or something..

Nao 尚

Ahhh...! The infamous gc_probability setting. On one of my servers (forum.cyna.net), this was set to 0 indeed. Meaning that the garbage collector had zero chance of being triggered. I remember spending something like a month with my server admin trying to figure out why the session tables wouldn't empty like they do on my other (shared hosting) server. In the end, I found out about gc_probability, and that was it.
My server admin always thought the variable was reset unknowingly by another admin. I will have to tell him this was due to a bug in Debian ;)
Thanks for the tip!
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Daniel15

QuoteI will have to tell him this was due to a bug in Debian
Not a bug, a feature ;)
Read the technical explanation I posted :)
Daniel15, former Customisation team member, resigned due to lack of time. I still love everyone here :D.
Go to smfshop.com for SMFshop support, do NOT email or PM me!

Nao 尚

Quote from: Daniel15 on February 05, 2008, 09:49:06 PM
QuoteI will have to tell him this was due to a bug in Debian
Not a bug, a feature ;)
Read the technical explanation I posted :)
I'm not sure he understood it either  O:)
I will not make any deals with you. I've resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.

Aeva Media rocks your life.

Advertisement: