4

I have recently been assigned to a project that has regular session table crashes.

Drupal outputs an error like this one: "Warning: Table './[database]/sessions' is marked as crashed and should be repaired ..."

The problem with this site is that it started as a small drupal site and various companies have added (custom) modules to it. The site has also been ported to a number of different hosting providers with varying results. Currently it is being hosted at OVH on a shared hosting setup.

The site is rather large now with a constant base of 20 users inserting data simultaniously (on different accounts but through the drupal interface), mostly pictures through a multi upload module. At the same time there is a lot of traffic coming from anonymous users (who do not upload anything at this point).

I think the problem might be the shared hosting platform. I think it might not be able to cope with all of the different inserts and just crashes... Normally I would see if I could cause the crash in some way, but I can't take the site down since it will result in a major financial loss to the company.

I've read some other posts here regarding a large session table where they mentioned the "ini_set('session.gc_maxlifetime', 200000);" line in the settings.php file. The "answer" was to reduce the amount of sessions to 900-1800 which would result in a smaller session table, but I don't know if this would solve the problem?

To make matters worse my client cannot give me any information on when the crashes occur, if they are perhaps caused by using a custom module, etc. The site is running on Drupal 6.

I realize there is not a lot of useful information in my post and I apologize for that. I am a new Drupal developer and I don't know how to address this problem. (The developer who was handling this issue before I got here quit...)

Any help in this matter would be appreciated.

Thank you.

Improve this question
5
  • 1
    So does the problem reoccur after doing REPAIR TABLE 'sessions' (or 'repair table' option in phpMyAdmin)? (edit: should be backquotes around sessions, markdown filter)
    – arjan
    Commented May 14, 2012 at 0:33
  • Yes, it does. REPAIR TABLE does solve the problem temporarily. The time it takes for the table to crash again varies. All the tables are MyISAM and I found out I might be able to solve it by converting the table to InnoDB or perhaps or adding the following code to my /etc/my.cnf file : [mysqld] myisam-recover=backup,force . But both of these solutions seem more like patches instead of fixes?
    – Mike
    Commented May 14, 2012 at 11:04
  • 1
    I'm no expert in this area, but I would say this is most likely due to your server configuration (e.g. running out of disk space, connection to DB-server timed out), rather than a problem with Drupal (custom) modules. So you should also check the MySQL and other server logs. But converting write-intensive tables such as sessions (perhaps even all tables) to InnoDB seems like it's worth a shot (see this for example).
    – arjan
    Commented May 14, 2012 at 15:53
  • Thanks, I'll give that a try and post back here when I have some more information. Thanks for your help :)
    – Mike
    Commented May 15, 2012 at 13:31
  • @arjan Thanks for your help. Converting to InnoDB solved the crashes for the most part and it seemed that the hosing was causing some of the other problems. We converted some tables to innoDB and changed the hosting and it is running fairly well now.
    – Mike
    Commented Jul 31, 2012 at 8:06

1 Answer 1

Reset to default
1

I would convert the user & session tables to InnoDB. I would also check the memory limits for MySQL. It's not the most ideal tool, but if you're in a shared environment you can install a copy of Drupal Tweaks (http://drupal.org/project/drupal_tweaks) and see if you are able to alter any of the MySQL configuration directive such as memory limit.

Improve this answer
3
  • That will come in handy, thanks! Right now, both the users and session tables are in InnoDB and they are working just fine. There were some crashes on some of the cache tables however. There was also a 'mysql server has gone away error' which I might be able to solve with your link. My next step is to convert everything to InnoDB as suggested by @arjan and see how that goes. I will post back with the outcome.
    – Mike
    Commented Jun 9, 2012 at 8:52
  • mysql server has gone away likely indicates it ran out of memory and crashed. I don't see any problem with setting them all to InnoDB. I did the on a recent D6 install and haven't had any problems (yet).
    – Charlie Schliesser
    Commented Jun 9, 2012 at 22:37
  • Exactly. The biggest problem here was the shared hosting.
    – Mike
    Commented Jul 31, 2012 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.