-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Database based file locking creates many DELETE statements #22819
Comments
I thought we originally already said this has to be done in a background job ? @DeepDiver1975 @icewind1991 |
It's a 8.2.2 instance. |
This killed a bigger instance -> raising sev |
Workaround: Commenting core/lib/private/lock/dblockingprovider.php Line 265 in e191953
mysql DBNAME --execute "DELETE FROM oc_file_locks WHERE ttl < $(date +%s);" |
Moving to 9.0.1 then, doesn't look good |
I agree that it should be fixed... but why is a larger instance using db locking? |
Why not - only drawback should be "it is slower" but not "it kills the whole DB cluster". The DB is flooded with those statements. |
Fix is here: #22865 |
* fixes #22819 The old way fired a DELETE statement on each destruction of the DBLockingProvider. Which could cause a lot of queries. It's enough to run this every 5 minutes in a background job, which in the end could result in file locks that exists 5 minutes longer - in the worst case and for not properly released locks. This makes the DB based locking a lot more performant and could result in a similar performance to the Redis based locking provider.
* fixes #22819 The old way fired a DELETE statement on each destruction of the DBLockingProvider. Which could cause a lot of queries. It's enough to run this every 5 minutes in a background job, which in the end could result in file locks that exists 5 minutes longer - in the worst case and for not properly released locks. This makes the DB based locking a lot more performant and could result in a similar performance to the Redis based locking provider.
* fixes #22819 The old way fired a DELETE statement on each destruction of the DBLockingProvider. Which could cause a lot of queries. It's enough to run this every 5 minutes in a background job, which in the end could result in file locks that exists 5 minutes longer - in the worst case and for not properly released locks. This makes the DB based locking a lot more performant and could result in a similar performance to the Redis based locking provider.
* fixes #22819 The old way fired a DELETE statement on each destruction of the DBLockingProvider. Which could cause a lot of queries. It's enough to run this every 5 minutes in a background job, which in the end could result in file locks that exists 5 minutes longer - in the worst case and for not properly released locks. This makes the DB based locking a lot more performant and could result in a similar performance to the Redis based locking provider.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
We noticed this.
@icewind1991 @PVince81 Could this be caused by
core/lib/private/lock/dblockingprovider.php
Line 265 in e191953
I guess we need to move to a background job?
The text was updated successfully, but these errors were encountered: