Certain tables of my forum keep breaking over night (i.e. log sessions, log online, and smf members). There is an option to automatically repair broken tables in SMF, but to my knowledge it is not working, because I'm waking up to these broken tables. So how does SMF recognize broken tables? I am now tempted to start a cron job that would repair my MYSQL every hour or so, but I think the forum software should do what it says it does. I am using SMF 1.x. Please let me know what's wrong and how SMF works to recognize a table is in fact broken,
// Check for errors like 145... only fix it once every three days, and send an email. (can't use empty because it might not be set yet...)
if (!empty($fix_tables))
I think that if tables crash every day there is something else...
Quote from: emanuele on November 30, 2012, 10:30:53 AM
// Check for errors like 145... only fix it once every three days, and send an email. (can't use empty because it might not be set yet...)
if (!empty($fix_tables))
I think that if tables crash every day there is something else...
Yeah, there are plenty php5-cgi processes running at once, which are eating away at the ram. The forum works well, but not sure why these are running, could be an apache misconfiguration. So, why aren't tables being fixed automatically? Could something be conflicting with that option?
I suppose that the idea is: once in a while MySQL may fail and so let's try to repair it. But if it fails more frequently it means there is something serious that should be fixed instead, so let's notify the admin and wait.
Quote from: emanuele on November 30, 2012, 11:30:09 AM
I suppose that the idea is: once in a while MySQL may fail and so let's try to repair it. But if it fails more frequently it means there is something serious that should be fixed instead, so let's notify the admin and wait.
Yeah, I'm trying to figure out what's causing the php5-cgi processes to run uncontrollably.
Check this out: http://biology-forums.com/status.php
Well, if you want to fix the tables more frequently you can change:
if (@$db_last_error < time() - 3600 * 24 * 3)
to something else.
3600 * 24 * 3 means 3 days (3600 seconds/hour, 24 hours/day, 3 days)
Quote from: emanuele on November 30, 2012, 11:38:07 AM
Well, if you want to fix the tables more frequently you can change:
if (@$db_last_error < time() - 3600 * 24 * 3)
to something else.
3600 * 24 * 3 means 3 days (3600 seconds/hour, 24 hours/day, 3 days)
If I change it to every hour, is that fine? What would be the code?
Quote from: stylusss on November 30, 2012, 12:22:34 PM
If I change it to every hour, is that fine?
No idea.
Quote from: stylusss on November 30, 2012, 12:22:34 PM
What would be the code?
if (@$db_last_error < time() - 3600)
Do you have Xcache installed along with the PHP5-CGI? Most people have had problems with it while installed such as your case. Anyways, it sounds more like a problem you should ask your Hosting Provider to look into.
Quote from: frostalf on December 05, 2012, 12:55:48 PM
Do you have Xcache installed along with the PHP5-CGI? Most people have had problems with it while installed such as your case. Anyways, it sounds more like a problem you should ask your Hosting Provider to look into.
I removed Xcache because it was conflicting with my mediawiki.
If your using apache and don't really need FastCGI you could go with the apache PHP mod which seems to work better. Things like xcache or memcache with cgi tends to not work well. But there might be a misconfigured setting in your fast-cgi config file. But your best route to solving memory leak is notifying your Server's Support team. They would have better knowledge and more logs on as to what exactly is happening. But as I said, if you don't need cgi maybe see if you can use the PHP mod for apache, that is if your using the apache server. Also, there could be a memory leak in a mod or cgi script as well. So it can be a number of things, but I highly suggest contacting Your Host's support to solve this. Memory leaks are bad and could destroy a system.
Why does SMF choose to repair errors every three days? Why wouldn't they default it at 1 day or half day?
Don't you think three days is too long to finally repair a database error? That would mean the forum would be out of commission for three days before anything gets fixed, right?
Quote from: emanuele on November 30, 2012, 11:30:09 AM
I suppose that the idea is: once in a while MySQL may fail and so let's try to repair it. But if it fails more frequently it means there is something serious that should be fixed instead, so let's notify the admin and wait.
:-\ Doesn't answer my question.
Why did the designers of SMF choose three days?
Because it's a good middleground.
If it fails more often, something is wrong and the problem is bigger than anything to do with SMF.
Constantly repairing crashing tables is not the way to go. Letting a forum owner rely on a quick auto-repair behaviour as if it's normal is a bad thing to do.
An informed forum owner will want to investigate as soon as they obtain that first notice. I believe it's a flawed designed ...
An informex forum owner doesn't wait 3 days for the second occurrence of the corruption to appear. ;)
ETA: I see where the problem is, you don't know the code behind this but you are judging the implementation.
The code looks for broken tables every day, it doesn't wait three days to find a broken table. It **fixes** the table only three times every three days.
The design, as I explained earlier, is intended to fix an occasional error (maybe due to hosting temporary issues), but is designed so that an admin will know sooner or later (actually he should always know there is a problem because an automatic email is sent to him), that a less-temporary problem occurred to the host and something is broken.
So, no, the design is not flawed.