Moodle

global teacher viewing participants issues

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.9
  • Fix Version/s: 1.9
  • Component/s: Roles / Access
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_19_STABLE

Description

I have a global teacher assigned. In one of the courses, there are 400 students.

When the teacher tries to view the participants list, it takes a long time to load (loads ok) and I see

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 6815786 bytes) in Unknown on line 0

At the bottom of the page. When logging in as admin and viewing this participants list, I have no problem. I checked the SQL log, apart than seeing all the user level context paths gets updated every time, I do not see anything strange going on.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martín Langhoff added a comment -

Just pushed out a commit that might fix this problem by joining the participants against context, and saving the get_context_instance() calls. But I could not repro the insane memory usage you are seeing, even with a couple hundred students, so I am not 100% positive that I've nailed the problem you saw. And the "full" participants view is really bad in terms of DB usage.

BTW, the whole participants list needs a full rewrite to do smarter SQL, have better abstraction, and display more interesting data (RA locality, RA plugin, etc). Not before the merge, but I'll try to get time to do one late in the 1.9 series.

Show
Martín Langhoff added a comment - Just pushed out a commit that might fix this problem by joining the participants against context, and saving the get_context_instance() calls. But I could not repro the insane memory usage you are seeing, even with a couple hundred students, so I am not 100% positive that I've nailed the problem you saw. And the "full" participants view is really bad in terms of DB usage. BTW, the whole participants list needs a full rewrite to do smarter SQL, have better abstraction, and display more interesting data (RA locality, RA plugin, etc). Not before the merge, but I'll try to get time to do one late in the 1.9 series.
Hide
Permalink
Yu Zhang added a comment -

Good work, I am not seeing the memory error anymore, participant page load still takes around 20 seconds. I used nic's generator script (available in contrib) to generate 20k users, and assigned 400 per course.

17.82439 secs
RAM: 63MB
Included 38 files
DB queries 28
Log writes 1
ticks: 1782
user: 1233
sys: 15
cuser: 0
csys: 0
Load average: 1.16
Record cache hit/miss ratio : 0/0

Show
Yu Zhang added a comment - Good work, I am not seeing the memory error anymore, participant page load still takes around 20 seconds. I used nic's generator script (available in contrib) to generate 20k users, and assigned 400 per course. 17.82439 secs RAM: 63MB Included 38 files DB queries 28 Log writes 1 ticks: 1782 user: 1233 sys: 15 cuser: 0 csys: 0 Load average: 1.16 Record cache hit/miss ratio : 0/0
Hide
Permalink
Martín Langhoff added a comment -

Thanks for the feedback.

There must be something else different between our setups though - I can't make it go past 16MB memory usage. I can see only 2 memory pigs, one fixable (use of get_records()) and one not-so-fixable (the buildup of all the table HTML in memory).

... I've switched from get_records() to recordsets. Committed and pushed out. Shaves a bit of memory usage on my setup (but not that much, 1MB per 100 users?). Can you test it?

Are you perhaps using a 64bit environment – leading to larger data structures perhaps?

Show
Martín Langhoff added a comment - Thanks for the feedback. There must be something else different between our setups though - I can't make it go past 16MB memory usage. I can see only 2 memory pigs, one fixable (use of get_records()) and one not-so-fixable (the buildup of all the table HTML in memory). ... I've switched from get_records() to recordsets. Committed and pushed out. Shaves a bit of memory usage on my setup (but not that much, 1MB per 100 users?). Can you test it? Are you perhaps using a 64bit environment – leading to larger data structures perhaps?
Hide
Permalink
Martín Langhoff added a comment -

Yu - can you retest with the latest code to check memory usage? thanks!

Show
Martín Langhoff added a comment - Yu - can you retest with the latest code to check memory usage? thanks!
Hide
Permalink
Yu Zhang added a comment -

Hi ML, no luck, still pretty much the same

17.458757 secs
RAM: 63MB
Included 38 files
DB queries 28
Log writes 1
ticks: 1746
user: 1266
sys: 19
cuser: 0
csys: 0
Load average: 1.13
Record cache hit/miss ratio : 0/0

Show
Yu Zhang added a comment - Hi ML, no luck, still pretty much the same 17.458757 secs RAM: 63MB Included 38 files DB queries 28 Log writes 1 ticks: 1746 user: 1266 sys: 19 cuser: 0 csys: 0 Load average: 1.13 Record cache hit/miss ratio : 0/0
Hide
Permalink
Martin Dougiamas added a comment -

Is this still a problem?

Show
Martin Dougiamas added a comment - Is this still a problem?
Hide
Permalink
Martin Dougiamas added a comment -

I'm guessing not.

Show
Martin Dougiamas added a comment - I'm guessing not.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.