by Johnny Lo.
We upgraded MS SQL to 2019 this morning. Benchmark database performance is roughly the same as before.
I have these in config.php
$CFG->dboptions = array (
'LoginTimeout' => 30,
'dbpersist' =>0,
'dbport' => '',
'dbsocket' => '',
$CFG->dboptions = array (
'LoginTimeout' => 30,
'dbpersist' =>0,
'dbport' => '',
'dbsocket' => '',
);
I tested restore of a 30Mb math course. 2 times it failed within a few minutes mark with error that reads:
504 Gateway Time-out
The server didn't respond in time.
PHP error is logged as followed.
[19-Jul-2022 08:44:02 America/Los_Angeles] Default exception handler: error/restore_not_executable_awaiting_required Debug:
Error code: restore_not_executable_awaiting_required
$a contents: 800
* line 165 of \backup\util\plan\restore_plan.class.php: restore_controller_exception thrown
* line 394 of \backup\controller\restore_controller.class.php: call to restore_plan->execute()
* line 219 of \backup\util\ui\restore_ui.class.php: call to restore_controller->execute_plan()
* line 143 of \backup\restore.php: call to restore_ui->execute()
Query timeout on SQL server was set to unlimited when for the test so that is not it.
The server didn't respond in time.
PHP error is logged as followed.
[19-Jul-2022 08:44:02 America/Los_Angeles] Default exception handler: error/restore_not_executable_awaiting_required Debug:
Error code: restore_not_executable_awaiting_required
$a contents: 800
* line 165 of \backup\util\plan\restore_plan.class.php: restore_controller_exception thrown
* line 394 of \backup\controller\restore_controller.class.php: call to restore_plan->execute()
* line 219 of \backup\util\ui\restore_ui.class.php: call to restore_controller->execute_plan()
* line 143 of \backup\restore.php: call to restore_ui->execute()
Query timeout on SQL server was set to unlimited when for the test so that is not it.
The questions.xml in question is 10Mb. The files were created at 8:37am server time. The restore error on PHP is stamped at 8:44:02am. My timer clocked close to 4 minutes when it failed.
We have turned off virus scan on the moodle data directory which had greatly helped file write performance already. But as of now it is still no luck.