[Koha-devel] Koha sessions table is ridiculously huge

Clay Fouts clay.fouts at liblime.com
Wed Feb 17 21:12:20 CET 2010


Sessions are created for every OPAC session, too, even if they're not logged
in with a login/password. And consequently there's no way to log those out.


On Wed, Feb 17, 2010 at 11:14 AM, Walls, Ian <Ian.Walls at med.nyu.edu> wrote:

>  Clay,
>
>
>
>
> Thanks!  That sounds like an easy enough enhancement to make.  I’ll make it
> a point to keep an eye on the sessions table until then, and remind my
> coworkers to logout properly.
>
>
>
> Cheers,
>
>
>
>
>
> -Ian
>
>
>
> *From:* koha-devel-bounces at lists.koha.org [mailto:
> koha-devel-bounces at lists.koha.org] *On Behalf Of *Clay Fouts
> *Sent:* Wednesday, February 17, 2010 2:04 PM
> *To:* Koha-devel
> *Subject:* Re: [Koha-devel] Koha sessions table is ridiculously huge
>
>
>
> You can also use "truncate sessions" to do the job if you just want to
> clear out the contents of the table. It's faster and simpler than using
> mysqldump.
>
> This issue arises from the fact that the way Koha is written, if a user
> just walks away from a session without logging out, their session data will
> hang out in the the sessions table forever. A proper solution would involve
> adding a timestamp column to the sessions table, enabling one to cull only
> expired sessions entirely within SQL statements. With the current schema,
> you'd have to parse the contents of each row within a user program, then
> cull based on the expiry contained within the session data itself.
>
>
>
> Cheers,
>
> Clay
>
>
>
>
>
> 2010/2/17 Walls, Ian <Ian.Walls at med.nyu.edu>
>
> Developers,
>
>
>
>
>
> After performing a software upgrade and server reboot, I came across this
> problem.  My koha.sessions table is over 13 million entries.  This seems to
> indicate that entries into the table were never removed, and that may help
> to explain why my backup mysqldumps are increasing by around 4MB daily.
>
>
>
> Chris Cormack suggested that I do a mysqldump of sessions with the no-data
> option set, then reimport it into the database to clear it out.  I’ve
> finally gotten sessions to tell me what indexes it has on it, so that can be
> recreated as well.  Are there any risks to doing this that I’m not factoring
> in?
>
>
>
> More generally, what could be causing my sessions table to get so out of
> hand?  Permissions, perhaps?  Something in the code being off?
>
>
>
> Any ideas or feedback would be appreciated.  Thanks!
>
>
>
>
>
>
>
> Ian Walls
>
> Systems Integration Librarian
>
> NYU Health Sciences Libraries
>
> 550 First Ave., New York, NY 10016
>
> (212) 263-8687
>
>
>
>
>
> ------------------------------------------------------------
> This email message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain information that is proprietary,
> confidential, and exempt from disclosure under applicable law. Any
> unauthorized review, use, disclosure, or distribution is prohibited. If you
> have received this email in error please notify the sender by return email
> and delete the original message. Please note, the recipient should check
> this email and any attachments for the presence of viruses. The organization
> accepts no liability for any damage caused by any virus transmitted by this
> email.
> =================================
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>
>
>
>  ------------------------------------------------------------
> This email message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain information that is proprietary,
> confidential, and exempt from disclosure under applicable law. Any
> unauthorized review, use, disclosure, or distribution is prohibited. If you
> have received this email in error please notify the sender by return email
> and delete the original message. Please note, the recipient should check
> this email and any attachments for the presence of viruses. The organization
> accepts no liability for any damage caused by any virus transmitted by this
> email.
> =================================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100217/6e4c0927/attachment-0003.htm>


More information about the Koha-devel mailing list