[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