[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Heart-stopping _mproapsv memory usage in PASOE !

Status
Not open for further replies.
D

dbeavon

Guest
>> There isn't a size limit setting for PASOE on agent memory consumption. I'll pass along this thread to the right team. Did this idea ever go anywhere? I think it is reasonable to put constraints on the memory usage in _mproapsv. It is unreasonable to allow those crazy processes to grow indefinitely. We should be able to ask PASOE to put an upper limit on the memory that can be consumed. It surprises me that there isn't yet any configuration for this type of thing - considering the persistent leaks. In OE v.11.7.4 we had encountered a memory leak and created a repro and sent it to Progress and they supposedly fixed it. But we still see a few hundred MB leaking out of certain _mproapsv's every day, even now that we've upgraded to the "fixed" version 11.7.5. I knew that there would still be some level of a leakage, but did not expect it to be 100's of MB per day. It is pretty disappointing considering the amount of effort that is involved on our end to help Progress to fix these memory issues. Maybe most PASOE customers consider this to be an acceptable amount of memory to leak? Has anyone else observed steady leaks of msagents on Windows or Linux? I'd love it if Progress would really take ownership of this problem. Perhaps they could review memory dumps for anyone affected.... Ideally we would just wait for the process to grow to a certain size, say 2 or 3 GB, then we'd trim all the ABL sessions out of it (analogous to a "freshly started" _mproapsv). Then we'd take a memory dump of it, zip it up, and send it over to Progress. I'd guess that someone over there would be able to crack that thing open and figure out what the actual contents are. Unfortunately Progress doesn't seem eager to offer this service. In fairness, I believe there are some REST interfaces to extract certain diagnostic details about the contents of the msagent memory. But they only work with memory that is currently "associated" with the current ABL sessions (lets call this "managed" memory for lack of a better term). However in our case we've observed that we can trim *every* single ABL session from the msagent process and the committed memory size does not decrease (ie. the leak seems to be happening outside of "managed" memory). Aside from the CLR bridge we do not use anything but normal memory that is "managed" within an ABL session. IE we are *not* using ActiveX, COM-HANDLEs, MEMPTRs or whatever. (I will review managed memory in the bridge once again, but that has never turned out to be a significant source of our leaks). Are there other PASOE customers who are still struggling with runaway memory (100s of MB per day)? It would be nice to hear how you are dealing with it. Personally I think that a memory constraint in PASOE is a reasonable feature, considering how challenging it is to plug all the memory leaks. Basically it would work in a way that is analogous to a "resource timeout" but would kill off the agent after its memory size reached an excessive level (maybe 2 or 3 GB). This is a configuration that could be enabled by *default* for every customer (especially if it was set high enough, say 30 GB or whatever ;-).

Continue reading...
 
Status
Not open for further replies.
Top