[SERVER-12548] add indexes to config.locks and lockpings collection for large numbers of sharded collections Created: 30/Jan/14  Updated: 11/Jul/16  Resolved: 13/Feb/14

Status: Closed
Project: Core Server
Component/s: Performance
Affects Version/s: None
Fix Version/s: 2.4.10, 2.6.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Greg Studer Assignee: Greg Studer
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-15691 acquiring balancer lock may fail and ... Closed
Participants:

 Description   
Issue Status as of March 31, 2014

ISSUE SUMMARY

For certain use cases, the number of sharded collections can grow to such a number that distributed locking slows due to lack of indexes over the lock entries in the config database.

USER IMPACT

Sharding operations that require distributed locks (like splitting and moving chunks) can be delayed or blocked on systems with a very large number of sharded collections.

SOLUTION

The fix is to add indexes to the config.locks and config.lockpings collections to make these queries faster.

WORKAROUNDS

Affected users can create the indexes manually. The indexes to create are:

config.locks: { ts : 1 }
config.locks: { state : 1, process : 1 }
config.lockpings: { ping : 1 }

Limiting the number of sharded collections per cluster or deploying more performant hardware for config servers can also alleviate the problem.

AFFECTED VERSIONS

All recent production release versions up to 2.4.9 are affected.

PATCHES

The fix is included in the 2.4.10 production release and the 2.5.5 development version, which will evolve into the 2.6.0 production release.

Original Description

For certain use cases, the number of sharded collections can grow to such a number that distributed locking slows due to lack of indexes over the lock entries.

Add default indexes to the distributed locks collection to make lock queries fast.



 Comments   
Comment by Randolph Tan [ 22/Jan/15 ]

Addendum: took out { unique: true } from { ts: 1 } index spec in the workaround section because of SERVER-15691.

Comment by Githook User [ 20/Mar/14 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-12548 add indexes to distlock collections backport
Branch: v2.4
https://github.com/mongodb/mongo/commit/d949d2f1c378a8230a2c24da4f1c431cca78a80c

Comment by Githook User [ 20/Mar/14 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-12548 add indexes to distlock collections backport
Branch: v2.5
https://github.com/mongodb/mongo/commit/d949d2f1c378a8230a2c24da4f1c431cca78a80c

Comment by Githook User [ 10/Feb/14 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-12548 make lockpings query more efficient for large nums of locks
Branch: master
https://github.com/mongodb/mongo/commit/4c53c496eab4d15c3b8c5782faf1bf5f879237ca

Comment by Githook User [ 10/Feb/14 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-12548 add indexes to config.lockpings and config.locks in mongos
Branch: master
https://github.com/mongodb/mongo/commit/a16bce1003951dbbd5559892a267d51995c7c6dc

Comment by Eliot Horowitz (Inactive) [ 02/Feb/14 ]

Where we clean up old lock pings:
https://github.com/mongodb/mongo/blob/v2.4/src/mongo/client/distlock.cpp#L138
We table scan config.locks, and the filter in memory.
We should move that filter to the db and put an index on config.locks.process

Generated at Thu Feb 08 03:28:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.