Slow courseware get operation

Epic Link

None

Activity

Show:
Nimisha Asthagiri
July 31, 2017, 3:14 PM

Looping back on this. As and I discussed on Thursday, we expect the number of UserPartitionTransformer objects to be on the O(number of blocks in the course).

ChristinaR
July 27, 2017, 2:34 PM

We enabled the EnrollmentTrackUserPartition in production on June 9th. https://github.com/edx/edx-platform/pull/15037. At that time, all courses with more than one CourseMode (which means this wouldn't impact courses on Edge) would have the dynamic EnrollmentTrackUserParititon created. I don't think any changes we made since then would have caused this to be hit more often.

Eric Fischer
July 27, 2017, 2:11 PM

State of things this morning: LMS is still seeing production issues, memory usage is partially suspected and is the lead I'm following on this ticket. The best lead we have right now, given the dumps I've looked into, is that the UserPartitionTransformer is being collect()-ed more than it needs to be (see gist links above).

's team has been working with UserPartitions semi-recently, and resident BlockStructure expert may be able to help as well - do you two have any theories why this transformer is so active? Anything we can do to make it be less active?

Eric Fischer
July 26, 2017, 8:34 PM

Looks like we're collect()-ing quite a lot on a UserPartitionTransformer: https://gist.github.com/efischer19/ed8b4eb106ecdad19666b06e0f656c9a#gistcomment-2160007

Eric Fischer
July 26, 2017, 8:18 PM

https://gist.github.com/efischer19/ed8b4eb106ecdad19666b06e0f656c9a

TransformerDataMap, TransformerData, and ReturnDict all jump at me as custom types that are very large here.

Priority

CAT-1

Assignee

Eric Fischer

Fix versions

None

Sprint

None

Story Points

None

Reporter

Eric Fischer