UserQuitCronjob unable to execute

DynamoGeek · Jan 20th 2018

For awhile now my UserQuitCronjob has failed to execute. Stack trace below. Let me know what information I can provide to help locate the cause.

Code

Could not execute statement 'DELETE FROM wcf1_user WHERE userID = ?'

Stacktrace:

#0 /webroot/wcf/lib/data/DatabaseObjectEditor.class.php(110): wcf\system\database\statement\PreparedStatement->execute(Array)
#1 /webroot/wcf/lib/data/user/UserEditor.class.php(73): wcf\data\DatabaseObjectEditor::deleteAll(Array)
#2 [internal function]: wcf\data\user\UserEditor::deleteAll(Array)
#3 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(354): call_user_func(Array, Array)
#4 /webroot/wcf/lib/data/user/UserAction.class.php(142): wcf\data\AbstractDatabaseObjectAction->delete()
#5 [internal function]: wcf\data\user\UserAction->delete()
#6 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(204): call_user_func(Array)
#7 /webroot/wcf/lib/system/cronjob/UserQuitCronjob.class.php(39): wcf\data\AbstractDatabaseObjectAction->executeAction()
#8 /webroot/wcf/lib/data/cronjob/CronjobAction.class.php(147): wcf\system\cronjob\UserQuitCronjob->execute(Object(wcf\data\cronjob\Cronjob))
#9 [internal function]: wcf\data\cronjob\CronjobAction->execute()
#10 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(204): call_user_func(Array)
#11 /webroot/wcf/lib/action/AJAXProxyAction.class.php(74): wcf\data\AbstractDatabaseObjectAction->executeAction()
#12 /webroot/wcf/lib/action/AJAXInvokeAction.class.php(104): wcf\action\AJAXProxyAction->invoke()
#13 /webroot/wcf/lib/action/AbstractAction.class.php(47): wcf\action\AJAXInvokeAction->execute()
#14 /webroot/wcf/lib/action/AJAXInvokeAction.class.php(63): wcf\action\AbstractAction->__run()
#15 /webroot/wcf/lib/system/request/Request.class.php(83): wcf\action\AJAXInvokeAction->__run()
#16 /webroot/wcf/lib/system/request/RequestHandler.class.php(94): wcf\system\request\Request->execute()
#17 /webroot/wcf/acp/index.php(9): wcf\system\request\RequestHandler->handle('wcf', true)
#18 {main}

SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction

Stacktrace

#0 /webroot/wcf/lib/system/database/statement/PreparedStatement.class.php(93): PDOStatement->execute(Array)
#1 /webroot/wcf/lib/data/DatabaseObjectEditor.class.php(110): wcf\system\database\statement\PreparedStatement->execute(Array)
#2 /webroot/wcf/lib/data/user/UserEditor.class.php(73): wcf\data\DatabaseObjectEditor::deleteAll(Array)
#3 [internal function]: wcf\data\user\UserEditor::deleteAll(Array)
#4 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(354): call_user_func(Array, Array)
#5 /webroot/wcf/lib/data/user/UserAction.class.php(142): wcf\data\AbstractDatabaseObjectAction->delete()
#6 [internal function]: wcf\data\user\UserAction->delete()
#7 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(204): call_user_func(Array)
#8 /webroot/wcf/lib/system/cronjob/UserQuitCronjob.class.php(39): wcf\data\AbstractDatabaseObjectAction->executeAction()
#9 /webroot/wcf/lib/data/cronjob/CronjobAction.class.php(147): wcf\system\cronjob\UserQuitCronjob->execute(Object(wcf\data\cronjob\Cronjob))
#10 [internal function]: wcf\data\cronjob\CronjobAction->execute()
#11 /webroot/wcf/lib/data/AbstractDatabaseObjectAction.class.php(204): call_user_func(Array)
#12 /webroot/wcf/lib/action/AJAXProxyAction.class.php(74): wcf\data\AbstractDatabaseObjectAction->executeAction()
#13 /webroot/wcf/lib/action/AJAXInvokeAction.class.php(104): wcf\action\AJAXProxyAction->invoke()
#14 /webroot/wcf/lib/action/AbstractAction.class.php(47): wcf\action\AJAXInvokeAction->execute()
#15 /webroot/wcf/lib/action/AJAXInvokeAction.class.php(63): wcf\action\AbstractAction->__run()
#16 /webroot/wcf/lib/system/request/Request.class.php(83): wcf\action\AJAXInvokeAction->__run()
#17 /webroot/wcf/lib/system/request/RequestHandler.class.php(94): wcf\system\request\Request->execute()
#18 /webroot/wcf/acp/index.php(9): wcf\system\request\RequestHandler->handle('wcf', true)
#19 {main}

Display More

SoftCreatR · Jan 20th 2018

Lock wait timeout exceeded; try restarting transaction

That's an issue with your local database server. Nothing, that WoltLab could fix for you.

**Alexander Ebert** · Jan 20th 2018

DynamoGeek Can you please check the result of the query below and then invoke the user quit cronjob manually through your ACP. If it worked, compare it to the output of the same query again.

SQL

SELECT COUNT(*) FROM wcf1_user WHERE quitStarted <> 0

In case it doesn't work even when invoked manually, please run this query to retrieve information on any deadlocks. As it may contain sensitive data I strongly recommend that you submit it through a ticket or by email to ebert@woltlab.com directly.

SQL

SHOW ENGINE InnoDB STATUS\G

DynamoGeek · Jan 21st 2018

The error I got was through the ACP. I also have similar failure issues with dailyCleanUp, userGroupAssignment, userBan, and emptyRecycleBin.

I ran the query you gave and received a count of 182. After attempting to run the query userQuit again (it failed the same way), I ran the query again and received a count of 182 again.

I sent the results of the InnoDB status command to you via email.

**Alexander Ebert** · Jan 23rd 2018

This has somewhat been resolved and is related to some long running queries when working with really large data sets.

Throwholics · Jan 23rd 2018

Quote from Alexander Ebert

This has somewhat been resolved and is related to some long running queries when working with really large data sets.

So it was in the end a problem from the databse server?

**Alexander Ebert** · Jan 23rd 2018

Quote from Throwholics

So it was in the end a problem from the databse server?

Yes… no… it's complicated. With very large data rows, some innocent-looking queries can slowly become an issue. Adding more and better hardware will only work up to some point, eventually an increase in execution times is inevitable and the peformance will start to degrade.

With this amount of data, it can also become significantly more difficult to figure out which query (or background task) is the real bottle-neck due to cross-table dependencies that can hide the true issue.

Throwholics · Jan 23rd 2018

Ah I do understand
I thought WSC is perfectly scaleable

**Alexander Ebert** · Jan 23rd 2018

Quote from Throwholics

Ah I do understand
I thought WSC is perfectly scaleable

It actually scales quite nicely, but working with about 80 million posts is a whole different story. At this point, MySQL itself can become the bottle-neck.

Throwholics · Jan 23rd 2018

Alright Probably the biggest WBB forum out there at the moment with 91 million posts

DynamoGeek · Jan 27th 2018

Now if it was only the most active. *big dramatic sigh* I'm trying!

I've run into a few things like this, but Alexander has always been quick to respond and very capable.

Like Alexander mentioned, for example, one of the things that's dog-slow is that little post indicator Throwholics is mentioning. When you have a few hundred thousand, maybe a million posts, it works fine. With a bajillion, it gets really, really slow to execute. Instead of doing that query "every so often" and caching it, I just fib just a little bit and return the max post ID instead. The alternative is letting a really long query hang up a bunch of queries waiting after it. It's off by a bit, but percentage-wise I'm still quite okay with it. I could grab a bit of info from the InnoDB info, but that's more effort than I'm willing to go through.

Overall, I couldn't be happier with Woltlab. The friendliness of the community is far superior to SMF in general, and (granted, due at least in part to its paid nature) the support is immensely superior.

UserQuitCronjob unable to execute

Participate now!

Share

Users Viewing This Thread