We upgraded our site to Moodle 3.0 from Moodle 2.4 yesterday the upgrade went well but we now cannot edit out storyline scorm packages.
We have 4 courses on the Moodle 3.0 LMS.
1 course has 41 modules with a total of around 170 sections and therefore 170 scorm packages. Another course has 1 scorm package installed. We can edit the scorm package in the course with just 1 but when we try and edit or install a new scorm package into the course with 170 the computer crashes and will not allow you to go elsewhere.
If we cannot find out what is causing this we will have no option but to rewind and return to Moodle 2.4
Hi, Steve -- Thanks for reaching out, and while I cannot speak to having used Moodle personally, there are quite a few others here in the community who utilize Moodle, and may have some insights to share.
And just to confirm, if you test one of the courses you have mentioned above via the SCORM Cloud, it is still functioning properly for you in that environment, correct? If so, you might find it advantageous to reach out to Moodle Support directly for additional technical input on the behavior you are experiencing since upgrading from 2.4 to 3.0.
1) Try adding your packages to a free MoodleCloud site - if they are quick to add there it points to a likely issue with the configuration/performance of your Moodle server.
2) Take a look at the Moodle Environment page under admin > server > environment and make sure all items are green - especially the messages about PHP accelerators(opcache)
3) If you aren't using many 3rd party plugins it's probably a good idea to try an upgrade to PHP 7 as this gives a really nice performance improvement too. (some 3rd party plugins don't provide support for PHP 7 yet)
4) There's a new Benchmark plugin that allows you to run some tests on your server to see how well it performs - I haven't used it myself yet but it gives some nice indicators on where your system might need to be improved - more detail on that plugin is here: https://moodle.org/mod/forum/discuss.php?d=335357
Thank you for replying regarding this problem. I will pass this info to our moodle hosts at CRB Ass. It would probably take me all day to word each module individually onto the cloud. I have never used it. Will CRB be able to transfer everything on mass?
i will advise them of your recommendations tomorrow. I spoke to Phil Mayor who recommended you as the man who would know so I was very pleased to see your name.
Could the reason by the size of the course having 41 modules and around 170 sections compared to the other course that has 1?
yeah - good point, the cloud might not be the right way to test 170 scorm packages - I have to admit some of the above post was a copy/paste from some other responses I've used in the past ;-)
What course format are you using in the course? - it might be interesting to see if a format that displays a single section on the screen at a time makes any difference?
It would also be interesting to know when/how the crash occurs - do you get a white screen? - how long does that take to appear and the browser stop running? - there might be a timeout value on your server that is being hit.
If you can get the page to run it might be interesting to add the peformance logging data to the bottom of the page under admin > server > debugging - would be interesting to see the number of db queries/memory usage required to run the page.
Hey Steve, I didn't say yesterday but thinking about it. It may be time to switch each of those individual courses into their own separate course. I know we originally built as a single course, but that was more to do with the structure of the moodle site.
I know it is a huge job, but moving forward it would make things more manageable, off topic but just a thought.
it probably wouldn't be too hard to write a php script that moved each section into a new course - drop me a line privately if that's something of interest.
It was good to talk with you yesterday. I agree with what you are saying, in fact I had the same idea yesterday but not to the same extend. I was thinking about breaking things done into the 3 topics the biggest being the individual tumour sites. Dan has come up with some ideas for me / CRB to try and hopefully we will crack this.
Although opcache is not compatible with our current version of PHP (5.4 with SuPHP), the Benchmark plugin indicates that our system resources are fine (a score of 143 points - "your Moodle seems to work perfectly").
The issue occurs only when a SCORM module is added/edited, and only in the large course that Steve refers to, which contains around 170 SCORM modules/packages. A 500 error page is eventually returned after 3-4 minutes, and the error written to the server log is 'Cannot obtain session lock for sid: [...]', which can be traced back to lib/classes/session/database.php, line 182. No debugging information is shown because no Moodle page is rendered.
Attempting to then navigate elsewhere in the site results in another delay, followed by either the same 500 error, or an onscreen Moodle error message: "Timed out waiting for session lock". The browser window must be closed and a new session started in order to continue.
Altering the session handlers in config.php doesn't seem to make any difference to the outcome, except that sometimes the Atto editor autosave error message ('Could not connect to the server') appears before the 500 error page, and sometimes it doesn't, but everything seems to point back to this session lock issue.
Phil's suggestion of splitting this very large course down into a number of more manageable courses is probably a good idea in any case (assuming that this can be done and existing usage data/scores maintained), but this will take some time to manage, so it would be great if in the meantime some way could be found to resolve this session lock issue on v3.x so that we can move forward with Steve's upgrade and not be stuck back on v2.4. We don't have the level of knowledge required to crack this ourselves unfortunately, so hopefully Dan or another expert can help...
yeah - don't go back to 2.4 if you can, it's just likely to cause other issues (let alone the number of known un-patched security issues with that branch)
Steve has sent me an e-mail as well so I'll follow up there... I wasn't clear if this happened on "save" of the editing/add scorm page or if it happend when just viewing the update/add module form?
If it happens on the "view" page I wonder if you might be able to try turning conditional activities off in the course to see if that helps? - I can't think of many reasons why a large number of activities within the course would affect the view page.
We've rolled back to v2.4 already while we try and figure this out on v3.1 in a test environment.
To clarify, we're able to view the 'add / update package' form fine; the problem occurs when clicking 'Save'. The AJAX stuff around deleting the SCORM .zip file and re-uploading the same .zip file also works fine. It does all seem to come back to this session lock issue when the new HTTP request is made.
We have scheduled in a system update tonight which will upgrade our PHP version to 5.5 and enable opcache, so I'll report back again once this is done...
ah - I'd suspect the course cache rebuild function to possibly be a suspect then. When you add a new activity to the course it destroys the course cache and rebuild's it. You may need to revisit the caching type used - particularly if you haven't configured MUC at all and have used the default settings. I've seen a rebuild of a large course take a big hit on the number of db queries it generates too. We've had some good success using Memcached for our servers.
Glad you got the help you needed here and I just wanted to let you know that responding via email includes your signature here so you're welcome to edit the post and remove that information.
I think you have correctly identified the problem. Upgrading PHP to v5.5 and enabling opcache didn't make any difference, but we have since also installed memcached server, created a memcached store in Moodle, and mapped this to the default application cache -- and this seems to have done the trick!
For me there are still questions about why Moodle apparently needs such a large amount of resource in order to make what should be pretty simple updates, but for now the problem seems to have been solved, so thank you very much Dan for all your help and suggestions -- without you we would have been quite stuck! We will now be able to proceed with our upgrade to v3.1 as planned.
Hi Dan Thank you for all the assistance, Craig has installed all that was suggested and we can now edit and install scorms. Thanks to Articulate, Phil Mayor, CRB Ass (Craig and the team) we will go "live" next Tuesday.
Awesome! - Moodle isn't a simple static application - it's pretty big these days so requires a bit of tweaking/specialist hosting knowledge to get it running well - it's constantly getting more complex too, with Global Search and auto-conversion to pdf in Moodle 3.1.
There are a bunch of different cache's in Moodle that are supposed to prevent multiple db calls to obtain data - but the problem is that when you leave things as the default without configuring MUC correctly you almost end up in a slower state.
Another thing that might be worth looking into at some point would be PHP 7 - we've seen some really nice performance improvements there as well. Only thing to be aware of is that some 3rd party plugins don't yet support PHP 7 and if you have any custom code it might need updating as well.
22 Replies
Hi, Steve -- Thanks for reaching out, and while I cannot speak to having used Moodle personally, there are quite a few others here in the community who utilize Moodle, and may have some insights to share.
And just to confirm, if you test one of the courses you have mentioned above via the SCORM Cloud, it is still functioning properly for you in that environment, correct? If so, you might find it advantageous to reach out to Moodle Support directly for additional technical input on the behavior you are experiencing since upgrading from 2.4 to 3.0.
Here are some things I'd suggest trying:
1) Try adding your packages to a free MoodleCloud site - if they are quick to add there it points to a likely issue with the configuration/performance of your Moodle server.
2) Take a look at the Moodle Environment page under admin > server > environment and make sure all items are green - especially the messages about PHP accelerators(opcache)
3) If you aren't using many 3rd party plugins it's probably a good idea to try an upgrade to PHP 7 as this gives a really nice performance improvement too. (some 3rd party plugins don't provide support for PHP 7 yet)
4) There's a new Benchmark plugin that allows you to run some tests on your server to see how well it performs - I haven't used it myself yet but it gives some nice indicators on where your system might need to be improved - more detail on that plugin is here: https://moodle.org/mod/forum/discuss.php?d=335357
Hi Dan
Thank you for replying regarding this problem. I will pass this info to our moodle hosts at CRB Ass. It would probably take me all day to word each module individually onto the cloud. I have never used it. Will CRB be able to transfer everything on mass?
i will advise them of your recommendations tomorrow. I spoke to Phil Mayor who recommended you as the man who would know so I was very pleased to see your name.
Could the reason by the size of the course having 41 modules and around 170 sections compared to the other course that has 1?
Thanks
Steve
Thanks Christie
i will look into the moodle forum, Dan has replied as well and I will pass both comments onto our Moodle hosts CRB Ass.
yeah - good point, the cloud might not be the right way to test 170 scorm packages - I have to admit some of the above post was a copy/paste from some other responses I've used in the past ;-)
What course format are you using in the course? - it might be interesting to see if a format that displays a single section on the screen at a time makes any difference?
It would also be interesting to know when/how the crash occurs - do you get a white screen? - how long does that take to appear and the browser stop running? - there might be a timeout value on your server that is being hit.
If you can get the page to run it might be interesting to add the peformance logging data to the bottom of the page under admin > server > debugging - would be interesting to see the number of db queries/memory usage required to run the page.
Thank you Dan
i will pass all this information to our hosts and get them to go through your comments. I really do not want to have to return to Moodle 2.4
Hey Steve, I didn't say yesterday but thinking about it. It may be time to switch each of those individual courses into their own separate course. I know we originally built as a single course, but that was more to do with the structure of the moodle site.
I know it is a huge job, but moving forward it would make things more manageable, off topic but just a thought.
it probably wouldn't be too hard to write a php script that moved each section into a new course - drop me a line privately if that's something of interest.
Hi Phil
It was good to talk with you yesterday. I agree with what you are saying, in fact I had the same idea yesterday but not to the same extend. I was thinking about breaking things done into the 3 topics the biggest being the individual tumour sites. Dan has come up with some ideas for me / CRB to try and hopefully we will crack this.
Thanks for the suggestions Dan.
Although opcache is not compatible with our current version of PHP (5.4 with SuPHP), the Benchmark plugin indicates that our system resources are fine (a score of 143 points - "your Moodle seems to work perfectly").
The issue occurs only when a SCORM module is added/edited, and only in the large course that Steve refers to, which contains around 170 SCORM modules/packages. A 500 error page is eventually returned after 3-4 minutes, and the error written to the server log is 'Cannot obtain session lock for sid: [...]', which can be traced back to lib/classes/session/database.php, line 182. No debugging information is shown because no Moodle page is rendered.
Attempting to then navigate elsewhere in the site results in another delay, followed by either the same 500 error, or an onscreen Moodle error message: "Timed out waiting for session lock". The browser window must be closed and a new session started in order to continue.
Altering the session handlers in config.php doesn't seem to make any difference to the outcome, except that sometimes the Atto editor autosave error message ('Could not connect to the server') appears before the 500 error page, and sometimes it doesn't, but everything seems to point back to this session lock issue.
Phil's suggestion of splitting this very large course down into a number of more manageable courses is probably a good idea in any case (assuming that this can be done and existing usage data/scores maintained), but this will take some time to manage, so it would be great if in the meantime some way could be found to resolve this session lock issue on v3.x so that we can move forward with Steve's upgrade and not be stuck back on v2.4. We don't have the level of knowledge required to crack this ourselves unfortunately, so hopefully Dan or another expert can help...
yeah - don't go back to 2.4 if you can, it's just likely to cause other issues (let alone the number of known un-patched security issues with that branch)
Steve has sent me an e-mail as well so I'll follow up there... I wasn't clear if this happened on "save" of the editing/add scorm page or if it happend when just viewing the update/add module form?
If it happens on the "view" page I wonder if you might be able to try turning conditional activities off in the course to see if that helps? - I can't think of many reasons why a large number of activities within the course would affect the view page.
Hi Dan,
We've rolled back to v2.4 already while we try and figure this out on v3.1 in a test environment.
To clarify, we're able to view the 'add / update package' form fine; the problem occurs when clicking 'Save'. The AJAX stuff around deleting the SCORM .zip file and re-uploading the same .zip file also works fine. It does all seem to come back to this session lock issue when the new HTTP request is made.
We have scheduled in a system update tonight which will upgrade our PHP version to 5.5 and enable opcache, so I'll report back again once this is done...
ah - I'd suspect the course cache rebuild function to possibly be a suspect then. When you add a new activity to the course it destroys the course cache and rebuild's it. You may need to revisit the caching type used - particularly if you haven't configured MUC at all and have used the default settings. I've seen a rebuild of a large course take a big hit on the number of db queries it generates too. We've had some good success using Memcached for our servers.
Hi Dan
Thank you for all the help / ideas to try and sort this problem out. I want to use 3.0 asap as my users really liked it.
We will try everything you have suggested and will reply to you as soon as we have.
Many thanks
Steve
Hi Dan
Thanks for this extra idea. Craig at CRB Ass will try and get this loaded.
Many thanks
Steve
Hey Steve,
Glad you got the help you needed here and I just wanted to let you know that responding via email includes your signature here so you're welcome to edit the post and remove that information.
Hi
Thank you for that. We have not sorted the problem yet Dan has been a big help and hopefully we will resolve things soon.
Steve
Hi Dan,
I think you have correctly identified the problem. Upgrading PHP to v5.5 and enabling opcache didn't make any difference, but we have since also installed memcached server, created a memcached store in Moodle, and mapped this to the default application cache -- and this seems to have done the trick!
For me there are still questions about why Moodle apparently needs such a large amount of resource in order to make what should be pretty simple updates, but for now the problem seems to have been solved, so thank you very much Dan for all your help and suggestions -- without you we would have been quite stuck! We will now be able to proceed with our upgrade to v3.1 as planned.
Thanks for that update Craig, and hopefully it's something that helps Steve too!
Hi Dan Thank you for all the assistance, Craig has installed all that was suggested and we can now edit and install scorms. Thanks to Articulate, Phil Mayor, CRB Ass (Craig and the team) we will go "live" next Tuesday.
Awesome! - Moodle isn't a simple static application - it's pretty big these days so requires a bit of tweaking/specialist hosting knowledge to get it running well - it's constantly getting more complex too, with Global Search and auto-conversion to pdf in Moodle 3.1.
There are a bunch of different cache's in Moodle that are supposed to prevent multiple db calls to obtain data - but the problem is that when you leave things as the default without configuring MUC correctly you almost end up in a slower state.
Another thing that might be worth looking into at some point would be PHP 7 - we've seen some really nice performance improvements there as well. Only thing to be aware of is that some 3rd party plugins don't yet support PHP 7 and if you have any custom code it might need updating as well.
all the best!
This discussion is closed. You can start a new discussion or contact Articulate Support.