> On June 26, 2015, 6:09 p.m., Tom Beerbower wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StageResourceProvider.java, > > lines 358-359 > > <https://reviews.apache.org/r/35945/diff/1/?file=993620#file993620line358> > > > > Doesn't setResourceProperty make the same check?
Yes it does, but with `setResourceProperty`, we have to pass in `entity.getCommandParamsStage()` which actually causes it to be populated. So, we'd be populating it even if it wasn't requested. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35945/#review89579 ----------------------------------------------------------- On June 26, 2015, 5:57 p.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35945/ > ----------------------------------------------------------- > > (Updated June 26, 2015, 5:57 p.m.) > > > Review request for Ambari, Nate Cole and Tom Beerbower. > > > Bugs: AMBARI-12178 > https://issues.apache.org/jira/browse/AMBARI-12178 > > > Repository: ambari > > > Description > ------- > > During an upgrade of a large cluster, the memory used by Ambari grows until > it is fully consumed. This, however, only happens when the Upgrade Dialog > page is open. If that popup is closed, the memory usage stays relatively > constant. Based on heap dumps, the larges offenders are StageEnity and, as a > result, byte[] > > Long story short here is that we have a cache in ActionDBAccessorImpl that > holds onto entities. Because of this, the underlying UnitOfWork map is never > released and holds onto all StageEntity instances. Eventually, items are > purged from this cache, but it's not fast enough to free up memory resources. > > Without ripping apart Ambari or making dangerous cache reference changes, the > easiest solution was to ensure that the fields causing the StageEntity to be > large were lazy loaded since most of the time these entities are just sitting > around in the EntityManager. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StageResourceProvider.java > 664fae3 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeGroupResourceProvider.java > eb34d63 > ambari-server/src/main/java/org/apache/ambari/server/orm/dao/StageDAO.java > b354841 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostEntity.java > 9f3f70c > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/StageEntity.java > c2b97d6 > > ambari-server/src/main/java/org/apache/ambari/server/topology/TopologyManager.java > 31363b4 > > Diff: https://reviews.apache.org/r/35945/diff/ > > > Testing > ------- > > Performed a cluster upgrade and monitored the memory usage. 200,000 > StageEntity used to occupy 3.5GB of heap; now they take up about 150MB. > > > Thanks, > > Jonathan Hurley > >
