I've had the same problem in a production site a while ago. The session table grew out of proportion, crashed and I couldn't repair it.
What I did was drop the table and recreated it. I didn't dig any further as it kind of solved the problem. I'll look at it again and tell you how this table behave.
I have had similar problem causing a full crash when we ran out of disk space. I think the problem is related to anonymous sesssions. Although I'm not sure, I belive there is a 'session' created for every request from the anynomous user, i.e. subsequent request for an anynomous user is not handled as one session but as many, casuing the sessiontable to fill up. Have a look in the admin interface under Sessions (and make sure to show all session for all users) to se the current number of sessions.
We have some high traffic sites that are just not affected, but they are MyISAM
I think it might have something to do with InnoDB. I have a gut feeling that the code that clears these does not finish its transction and this means that InnoDB roles back the transaction. I cannot prove it, but it just feels like that sort of problem.
Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development
We recently hit this issue again and the solution used was to drop the ezsession table and re-add it as myisam.
With mysql 4.1 we have a single innodb file which simply keeps growing. If you clear the session table the innodb size doesnt change, so we hit disk space issues because of this. Switching to myisam solves this because that table does clear down when sessions expire.
Does anyone know if innodb is better in recent mysql versions?
Once you get close to disk limits innodb rollbacks then start causing instabilities in the system...
Paul> the innoDB file will never decrease. The solution is to dump your bases with mysqldump, delete innoDB file, and then import the dump. See http://dev.mysql.com/doc/refman/4.1/en/adding-and-removing.html
For the Session table problem see this bug report : http://issues.ez.no/10431 In most case, It seems that it is related to the default config of Debian.
Yip, innodb is sometimes very inflexible. The point of ezsession is to not grow... Wonder if eZ needs to reconsider the table type for new installations or update the docs to make sure tables like this are always set to have their own separate file.
Our system is running on debian but that wasnt the issue. Simply invoking a sql 'DELETE' for huge ezsession caused timeouts and rollbacks - not pleasant! MyISAM may be more basic but it works quite well for the use this table is used for.