Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: sync tables without acquiring read lock the whole time #14179

Merged
merged 6 commits into from
Sep 27, 2024

Conversation

ashwanthgoli
Copy link
Contributor

@ashwanthgoli ashwanthgoli commented Sep 19, 2024

What this PR does / why we need it:

Table manager and Table grab a read lock for the entire duration when syncing tables and index sets respectively, this can prevent new tables and new indexsets from getting initialised while the rlock is held. This pr tries to reduce the possibility of sync calls affecting query time table and indexset initialisation by grabbing the lock only for accessing protected resource during the sync loop

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Checklist

  • Reviewed the CONTRIBUTING.md guide (required)
  • Documentation added
  • Tests updated
  • Title matches the required conventional commits format, see here
    • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
  • Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
  • For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
  • If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

@ashwanthgoli ashwanthgoli marked this pull request as ready for review September 20, 2024 05:02
@ashwanthgoli ashwanthgoli requested a review from a team as a code owner September 20, 2024 05:02
Copy link
Collaborator

@JoaoBraveCoding JoaoBraveCoding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, just one question. Is it still safe to call indexSet.Sync or table.Sync without holding a lock over t.indexSetMtx or tm.tablesMtx respectively? That's the only thing that poped into my head while reviewing

Copy link
Collaborator

@JoaoBraveCoding JoaoBraveCoding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm but I haven't tested it

@ashwanthgoli
Copy link
Contributor Author

ashwanthgoli commented Sep 24, 2024

Thanks @JoaoBraveCoding!
i had similar doubts, but the individual tables and indexsets are internally protected by their own lock. ForConcurrent which is used for querying does not hold the lock on table and indexset list either.

I have been running these change in our dev and ops env, no issues so far

@ashwanthgoli ashwanthgoli merged commit a584fb7 into main Sep 27, 2024
62 checks passed
@ashwanthgoli ashwanthgoli deleted the indexset-sync branch September 27, 2024 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants