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

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:

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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe


Programming list archiving by: Enterprise Git Hosting