[openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

Zane Bitter zbitter at redhat.com
Wed Jan 11 14:21:28 UTC 2017


On 06/01/17 16:58, Emilien Macchi wrote:
>>> It's worth reiterating that TripleO still disables convergence in the
>>> undercloud, so these are all tests of the legacy code path. It would be
>>> great if we could set up a non-voting job on t-h-t with convergence enabled
>>> and start tracking memory use over time there too. As a first step, maybe we
>>> could at least add an experimental job on Heat to give us a baseline?
>> +1. We haven't made any huge changes into that direction, but having
>> some info would be great.
> +1 too. I volunteer to do it.

Emilien kindly set up the experimental job for us, so we now have a 
baseline: https://review.openstack.org/#/c/418583/

 From that run, total memory usage by Heat was 2.32GiB. That's a little 
lower than the peak that occurred near the end of Newton development for 
the legacy path, but still more than double the current legacy path 
usage (0.90GiB on the job that ran for that same review). So we have 
work to do.

I still expect storing output values in the database at the time 
resources are created/updated, rather than generating them on the fly, 
will create the biggest savings. There may be other infelicities we can 
iron out to get some more wins as well.

It's worth noting for the record that convergence is an architecture 
designed to allow arbitrary scale-out, even at the cost of CPU/memory 
performance (a common trade-off). Thus TripleO, which combines an 
enormous number of stacks and resources with running on a single 
undercloud server, represents the worst case.

cheers,
Zane.



More information about the OpenStack-dev mailing list