SMF Support > Server Performance and Configuration

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

<< < (9/10) > >>

Phoestre:
Maybe someone should add that this has been fixed in SMF 2.0 RC3 to the first post?
My server is on Ubuntu Lucid and I was checking SMF source codes and what Daniel was saying is already implemented in the standart file. Not sure about other versions of 2.0, I just checked RC3. Also I haven't noticed any database related problems, I'll keep an eye on sessions, and drop a note here later.

emicd:
im running 1.1.11 is it already fixed?? otherwise im in a sheared enviroment, should i use database driven session or not? thx

(i mean i use a hosting that gave mi a /home/myuser account i think thats a sheared enviroment)

Owdy:

--- Quote from: Daniel15 on December 16, 2007, 08:00:14 PM ---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 ---


--- End quote ---


Seems this is changed in 1.1

ivan91tran:

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

--- End quote ---

Thanks a lot there OP. Quick question - does it matter which PHP version I have?

jamesmark991:
i can't understand your code but i am try..

Navigation

[0] Message Index

[#] Next page

[*] Previous page