Hi:

Recently we found in our site that the sessions table frecuently broke and starts to get hard disk space beyond the stars. Also, randomly our website broke and star to show messages like that:

Warning: Got error 127 from storage engine query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = '4b5350a9fad979cbfba61a25ddc6d6fa' in /usr/www/users/xxxx/xxxxx/includes/database.mysql.inc on line 172

and then

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /usr/www/users/xxxxxx/xxxxx/includes/database.mysql.inc:172) in /usr/www/users/xxxxxx/xxxxx/includes/bootstrap.inc on line 811

A drop of the sessions table returns back to normal.

We discover that custom pagers inflate the sessions table includin the node numbers of (seems) all post ... and we have almost 40.000 post on our website.

The error that Drupal give us on Watchdog looks like:

The table 'sessions' is full query: INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES ('b151c9946087200dd958c415e8becb6c', 0, 0, '66.249.65.178', 'custom_pagers|a:1:{i:1;a:2:{s:4:\"data\";s:168185:\"31625,31624,31623,....... here was a looooooooooooooooooooooooong list of nodes ...............13662,14088,14173,20513\";s:9:\"timestamp\";i:1217460708;}}', 1217460709) en la línea 172 del archivo /usr/www/users/xxxxxxxx/xxxxx/includes/database.mysql.inc.

The problem is that the table sessions gets 2 GB, and then, broke. We move Sessions from MyISAM to InnoDB to avoid the problem of the file size limit of the table, but: there is a way that to avoid that custom pagers add all this number nodes to the sessions table?

Thank you in advance.

CommentFileSizeAuthor
#2 patch48.patch3.92 KBScott Reynolds

Comments

XiMac’s picture

Category: bug » support
Scott Reynolds’s picture

Title: Custom Pagers and the sessions Table » Remove Session based caching
Version: 5.x-1.9 » 6.x-1.10-beta1
Status: Active » Needs review
StatusFileSize
new3.92 KB

Session based caching will not scale as the SESSION and all the rest get to large.

Even caching it in via cache_set() won't work in the current implementation as it doesn't respect dynamic arguments (a la tokens). you need to cache_set() via uid/arg1/.../argn. Even then i would question why we are saving all this serialized data. This has to be slower then a proper query against the node table. (SELECT nid WHERE..).

So i say remove this! :-D

Scott Reynolds’s picture

frankly im scared of the static caching as well. That can and will out grow the php memory limit

Scott Reynolds’s picture

... this is gone in the dev tarball. This is what i get for working on a year old release

Scott Reynolds’s picture

Status: Needs review » Closed (fixed)