Memcached Moodle site still DB row locking

Memcached Moodle site still DB row locking

by jerrett fowler -
Number of replies: 6

Hi,

I have set up memcached, confirmed in PHPinfo within the moodle site, for a particular 2.8.2 Moodle site. I can see memcached is working on the server. I checked the Session handling page and it looks a bit different from the 2.6.* version when I enabled it before. 

Anyway, even though memcached works, and I believe the site is connecting to memcached for sessions, it still throws these lock queries to the database. It floods the database with these DB locks to the moodle sessions table.

This seems different from 2.6.* when memcached is enabled, you wouldn't see any activity in the sessions table in the DB. But now in 2.8.2 I see all this activity. The problems come when I get thousands of these happening all at once and the database comes to a halt as a result of all the table locks. 

Any ideas?

Average of ratings: -
In reply to jerrett fowler

Re: Memcached Moodle site still DB row locking

by jerrett fowler -

Any help here?

I thought that when memcached was used for sessions there'd be *no* database activity. Anyone know why we're seeing this?

In reply to jerrett fowler

Re: Memcached Moodle site still DB row locking

by Matteo Scaramuccia -

Hi Jerret,
memcached is used as a cache store for MUC which is not related with Moodle sessions: you need to configure sessions using file system to avoid DB row locking, Administration > Site administration > Server > Session Handling, unchecking dbsessions.

If you want to use memcached for sessions too, you need to create a new separated memcached instance (even same hostname but different port) and configure it as the back-end for Moodle sessions. Refs.: https://docs.moodle.org/28/en/Session_handling#Memcached.

HTH,
Matteo

Average of ratings:Useful (2)
In reply to Matteo Scaramuccia

Re: Memcached Moodle site still DB row locking

by James McLean -

And, to add to that, the database table "mdl_sessions" is still used when memcached is used to track the existence of each session. The data for the session itself is stored in memcached so row locking is greatly reduced.

Average of ratings:Useful (1)
In reply to James McLean

Re: Memcached Moodle site still DB row locking

by jerrett fowler -
Is there some reason why it needs to still use the DB at all? Shouldn't it be able to store that information in memcached? Is there a way to offload that completely from the DB?

I find that having 130 sites on a single very large DB server (128Gigs + 24 CPU cores) still has issues with long queries resulting from a mass of resets and checks for sessions in the DB. Could this be better handled with MongoDB or something else? Or do they all still store things in the DB still?

Thanks for your clarity so far!
In reply to jerrett fowler

Re: Memcached Moodle site still DB row locking

by Matteo Scaramuccia -

Hi Jerret,
shortly, yes: it is required to track each session and to better manage things like the ones listed in https://moodle.org/mod/forum/discuss.php?d=212940#p951096. Now, MDL-31501 has landed into the main stream and the sessions code can use any back-end w/o lacking of some features.

Other features have been added on top of that core infrastructure e.g. MDL-47800, MDL-47803, MDL-47834.

HTH,
Matteo

Average of ratings:Useful (1)
In reply to Matteo Scaramuccia

Re: Memcached Moodle site still DB row locking

by jerrett fowler -

Thanks for your reply. Hopefully after moving all of our users over to memcached we will see lower activity in the database.