SMF Support > Server Performance and Configuration

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

(1/11) > >>

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:

--- Code: --- 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']))

--- End code ---

Replace with:

--- Code: --- 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']))

--- End code ---

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 :)

青山 素子:
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.

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:
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!

Navigation

[0] Message Index

[#] Next page

Go to full version