[
https://issues.apache.org/jira/browse/SOLR-17895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127309#comment-18127309
]
Amrit Sarkar commented on SOLR-17895:
-------------------------------------
Follow-up idea, left out of the PR to keep it small:
When the lock dirs were swept, {{makeLockPath}} first calls
{{exists(rootPath)}} before rebuilding the chain. The root is persistent and
almost always there, so that check is usually a wasted round trip. It could go:
* create the first-level dir directly
* only on {{NoNode}}, create the root with {{makePath}} and try again
That saves one ZK call per rebuild. It only matters after the dirs sat idle for
a sweep, not on the busy path, where the PR already brings lock creation down
from 2 calls to 1.
Happy to add it to this PR or open a separate issue if it's worth it.
> Persistent ZNodes are leaked when running Solr Cloud with distributed
> collection commands
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-17895
> URL: https://issues.apache.org/jira/browse/SOLR-17895
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 9.0, 10.0
> Reporter: Paul McArthur
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a collection command is executed in distributed mode
> (DistributedCollectionCommandRunner), an ephemeral ZNode is created to lock
> the collection, shard or replica that prevents other commands from executing
> concurrently and potentially conflicting with each other.
>
> The ephemeral nodes are created in a tree structure under
> {_}*distributedapi/collectionlocks*{_}, with persistent znodes created for
> collName
> collName/Locks
> collName/_shard
> collName/_shard/Locks
> collName/_shard/_replica
>
> These nodes are never deleted from ZooKeeper, even when the collection is
> deleted, and can therefore accrue over time.
> In our specific case, we have accumulated many thousands of these nodes over
> a few months. While there appears to be no direct impact on performance,
> these nodes should nonetheless be removed when they are no longer required.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
