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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
