Project

General

Profile

Bug #18127

IRM Slow memory leak

Added by Dennis Nicklaus about 3 years ago. Updated over 2 years ago.

Status:
Assigned
Priority:
Normal
Assignee:
Mike Sliczniak
Start date:
11/06/2017
Due date:
% Done:

0%

Estimated time:
Duration:

Description

The following is all as stated by Mike Kucera: There is a slow memory leak in the IRMs, seen in Main Injector and other places. After about 2 months, the system will run out of memory (or it is so fragmented as to be useless). These systems used to stay up for 1 year +. Kucera opines that it seems to have gotten bad since the new DPM was made the default for everyone, but that wasn't absolutely for certain.

History

#1 Updated by Richard Neswold about 3 years ago

  • Status changed from New to Assigned

Some information which may of use:

When DPM is readying a request to a front-end for the first time, it targets the GETS32 task. Ideally, a front-end should return ACNET_NOTASK if that protocol still isn't supported. LabView front-ends, for instance, don't pay attention to the ACNET header and treat GETS32 requests as RETDAT requests. The unintelligible reply tells DPM to downgrade the request to RETDAT.

If I remember correctly, the IRMs returned ACNET_NOTASK so DPM knew to downgrade to RETDAT. However, the IRM will have received a GETS32 request. If there's a small memory leak, it will build up as each new request will send the one GETS32 packet.

#2 Updated by Richard Neswold over 2 years ago

Does this still seem to be a problem? Was is fixed?

Also available in: Atom PDF