-
Notifications
You must be signed in to change notification settings - Fork 635
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
[5.x]: Deadlock found when trying to get lock on entries_authors table #15768
Comments
@yannkost Are you using the default web-based queue runner, or do you have an alternative setup (CLI/cron/daemon)? If the latter, do you have one queue runner set up or multiple? |
@angrybrad I do have the default queue runner that comes with the cms. |
@yannkost are the web servers in a load-balanced environment? |
@angrybrad I can't tell as I don't know the setup of the hosting. |
@angrybrad But it sometimes also happens on localhost, but more rarely. |
@angrybrad We ran in to the same issue. In our case it is a load-balanced webserver pointing to a single database.
|
Hi @angrybrad, just in case you need more examples. We are also running into deadlocks and we are running on a load balanced environment with 2 web servers and 2 workers, where we're using one daemon per worker. |
You say this happens locally for you (even if it is more rarely). From the stack trace, I’d audit these two bits of custom code to ensure that whatever database resources they are grabbing are released as quickly as possible and to see if adding mutexes around critical database queries would prevent multiple queries from accessing the same bits of information simultaneously on your logic. Added multiple queue runners (like using the default web-based ones) in a load-balanced environment can exacerbate the deadlock issue if the database is the point of resource contention.
@MGxpwr Assuming you’re using the default web-based queue runner, this applies:
Try getting it down to a single, dedicated queue runner and see if the behavior changes. https://craftcms.com/docs/5.x/system/queue.html#queue-runners Same - try getting it down to a single, dedicated queue worker and see if the behavior changes |
I'm seeing this locally too @angrybrad . I've disabled all third party plugins too. I only have Craft's Amazon S3 2.2.1 and CKEditor 4.3.1.
All I'm trying to do is go to Entries -> All Entries. I hit "New Entry" in upper right and pick our blog section. And I get the stacktrace I included at the bottom (not every time, maybe 2nd to 5th try) This flow does a post with the section and siteId to /index.php?p=cms%2Factions%2Fentries%2Fcreate&site=en_us&v=1730410887394 Then it redirects to /cms/entries/blogEntry/new?site=en_us with the PDOException for deadlock found... So I believe the issue is the flow of creating a new entry from All Entries. Nothing with the request stands out when comparing the POSTs but the one from All Entries can lead to exceptions. It is NOT an issue if I go to Entries -> Blog and then just hit "New Entry". There is no deadlock exception and the URL becomes something like this: /entries/blogEntry/4326244?site=en_us&draftId=23831&fresh=1 But... Entries -> All Entries -> New Entry (pick a section) leads to this (usually within 5 tries):
Here is the deadlock info from MySQL LATEST DETECTED DEADLOCK2024-10-31 15:07:35 132277298267712 *** (1) HOLDS THE LOCK(S): *** (1) WAITING FOR THIS LOCK TO BE GRANTED: *** (2) TRANSACTION: *** (2) HOLDS THE LOCK(S): *** (2) WAITING FOR THIS LOCK TO BE GRANTED: *** WE ROLL BACK TRANSACTION (2) |
@joshmcoffman Any chance that's on an environment we could get Craft control panel and SSH access to? If so, could you send to [email protected] and reference this issue? |
What happened?
Description
We have an import job for a website that sometimes fails due to a deadlock issue. (This happens like 1 times out of 3).
The text was updated successfully, but these errors were encountered: