Tim Armstrong has posted comments on this change. Change subject: IMPALA-5220: memory maintenance cleanup ......................................................................
Patch Set 5: (2 comments) The consumption metric refresh shouldn't be consequential. It previously was controlled by logbufsec, which defaulted to 5s. Also if there are queries actually running and checking memory consumption they'll force refresh of the metric, this mainly just exists to prevent it getting permanently out of sync while the system is idle. http://gerrit.cloudera.org:8080/#/c/6626/5//COMMIT_MSG Commit Message: Line 25: by the gperftools 2.4 upgrade). > that doesn't seem like a valid conclusion given that MemTracker::Release() I think this got confusing because it wasn't clear what "original problem" it was referring to. I meant IMPALA-2800, which was introduced by the ReleaseFreeMemory() calls, instead of the memory retention problem that the ReleaseFreeMemory() calls solved. Aggressive decommit made the ReleaseFreeMemory() calls unnecessary and also solved IMPALA-2800, because the ReleaseFreeMemory() calls didn't do any work and couldn't block the system. Line 29: was generally sensible. > I assume you reran this after the test? Did you happen to peak at RSS to i I did rerun it but didn't look at RSS. Just reran it and confirmed that RSS shrunk. -- To view, visit http://gerrit.cloudera.org:8080/6626 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0f822b294ab253d6f2828fc52f353aecaaf9b701 Gerrit-PatchSet: 5 Gerrit-Project: Impala-ASF Gerrit-Branch: master Gerrit-Owner: Tim Armstrong <[email protected]> Gerrit-Reviewer: Bharath Vissapragada <[email protected]> Gerrit-Reviewer: Dan Hecht <[email protected]> Gerrit-Reviewer: Matthew Jacobs <[email protected]> Gerrit-Reviewer: Tim Armstrong <[email protected]> Gerrit-Reviewer: anujphadke <[email protected]> Gerrit-HasComments: Yes
