News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

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

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

Previous topic - Next topic

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.

SMF 2.0RC3 + SimplePortal
Custom Theme + Latin5 Turkish
Ubuntu Lucid

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:

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



Seems this is changed in 1.1
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

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:

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

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


Shawanna

nice info i am using this os so i wanna change this immediately,i never had any idea about this

vkbr

Is this already on 2.0.1 right? I looked in my Load.php and this modifiacation was already been done...
thanks


Tansy

I've hunted around the SMF site, checked the manuals and this thread appears to be the best place to hopefully find an answer (or answers) ... and I will apologize up front if this appears to be step backwards, but most of the posts here are a couple of years old and there have been a few SMF upgrades since then and given that I am a novice at this, I don't wish to make more mistakes than absolutely necessary.

I've been running a SMF forum for a few years now and I am not a techie. My forum isn't large (or that's what I understand), runs on SMF 1.1.16, and I have only one theme mod (though I would like to add two more).   My Forum is seasonally busy, mostly from March to September and much quieter the rest of the year.  My Forum runs fine but it seems that some of the tables when I look at my databse in phpMyAdmin are very large. 

In particular:
   _sessions = 1,220,458 records / 670.0 MiB
   _messages = 60,693 records / 29.9 MiB
   _personal_messages = 6,118 records / 3.7 MiB
  ... the rest are all KiB and much smaller

It isn't really a surprise that _messages and _personal_messages are large just by their names - my members like to talk to one another both on the boards and via PM.  The _sessions file I'm afraid I just don't understand fully what all is being stored there and why is should be so very large, considering the size of my forum.  If someone could help me with a simpler explanation, I would appreciate it! 

I have never made a manual change to any of my SMF files, but from what I have read above, this might be necessary ... but before I do that, I would appreciate an opinion more knowledgeable than mine.  Or if there is something else I can/should do either in phyMyAdmin or SMF.

Thanks for everyone's patience on this.  My forum has/does run fine but I would prefer to proactively address problems if I can.  And if there isn't a problem, except in my lack of technical knowledge, that's fine too!  ;)  And if more information is needed, just let me know.

Tansy

PS - sorry, I can't say if my forum is a "Debian/Ubuntu Linux hosted forum", but if I know what to look for/ask about I can find out ...

medicMe

Forgive me if this has been answered already:

Does this problem still need manual correction on a Ubuntu 12.04 server with a fresh install of SMF 2.0.4?

Or has this been corrected over the last few years since the but/thread was first set sticky?


shadow82x

Colin B
Former Spammer, Customize, & Support Team Member



Arantor


leghorn23

Ideally you should be using something like memcache or even better redis for storing sessions. The performance will improve drastically. Just sayin'

Arantor

Except that most SMF users are on shared hosting where such things are not available.

Tansy

Wicked case of deja-vu all over again ... back in 2012, I had to back up my forum quickly as it seem to be degrading but because I had some very large dbase files, I was having trouble so I posted a message here for some information, can't remember if anyone pm'd me with an answer (link to post) (apologies) but somehow managed to backup and restore and forum has been working well.  Now I am in the same position again albeit for different reasons.

Now I am being inundated by error messages and from reading on other boards, that really my only option is to upgrade to SMF 2.x.x.  Fair enough, been hoping to find time to do that though I would have preferred it was during my less busy season - but needs must, so I delved back into what I needed to do to make a backup so I could upgrade it and keep my original forum intact until I've completed the upgrade.  (At the moment my forum is shut down).  Problem is that my _sessions file is ginormous (yes, we are getting technical now) and I have cannot for the life of me a) remember how I did it or b) find notes on what I did.  Rest of my forum files I have backed up very easily, it is just this _sessions file that is problematic, but no wonder it has 2million rows.

So what have I tried? (please note, I am a novice who knows just enough to get me in trouble)  I've tried to export the _sessions table separately, using myPHPadmin, by staggering the SQL download in 50,000 row segments but it stalls out when starting at row 300,001 - a long way from where I need to be.  I remember from last time how to stitch tables back together to import them but not how to get it downloaded in the first place.  I've looked at other software to stagger the dump, but am doing something wrong which is unsurprising as it likely has to do with configuration files or ? - this would be the trouble arising from a little bit of knowledge.

Anyone have any suggestions?  My frustration is starting to whisper the question "how important can the _sessions file really be" in my ear , so any ideas or suggestions would be appreciated  :o

Thanks!

vbgamer45

Not that important if you can clear it all or clear based on date/time. It just holds whether people are logged in or not. If cleared they will need to relogin and enter their username or password.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

Tansy

Quote from: vbgamer45 on April 23, 2017, 01:52:02 PM
Not that important if you can clear it all or clear based on date/time. It just holds whether people are logged in or not. If cleared they will need to relogin and enter their username or password.

Really?  If I have to do all the work to upgrade the forum so it continues to work for their enjoyment, I have no qualms about getting them to log in again.  Heck, I'll even give them a heads up so they can track down their logins or have me reset them!!  If I did just clear all the data, would you know would it reset?  Post counts?  (wouldn't think so)  Time online?  Anything else?  Not that I would really care in either of those examples, I can find other ways of giving them credit for being long-time members and its the price they would pay to have a forum that works ...

Arantor

If you just clear the sessions table, literally nothing else is affected other than 'they'll have to log in again'. It just tracks who is online right now.

Advertisement: