[WIP] [DEBUG] CONTAINER_INFLATE_FACTOR env var to duplicate most entities #14608
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@miq-bot add-label providers/containers, performance, wip
This is silly and incomplete but already useful to stress container refresh performance.
Plus more logging (TODO: separate PR with logging)
Usage:
Currently fails on wrong
@container_build_pod.container_build
but never mind.[untested] Should also work refreshing a live environment.
Be ready to reset your DB, especially if you vary CONTAINER_INFLATE_FACTOR...
TODO: does not inflate nodes & images.
Trying to understand what the customer may be hitting in https://bugzilla.redhat.com/show_bug.cgi?id=1436176. However, they have huge number of images, which this does not inflate :-(
First findings
https://gist.github.com/cben/4b8404346f42c917fd1aead993db895e
E.g.
CONTAINER_INFLATE_FACTOR=1000
sends my 12G laptop deep into swap...using https://github.com/jvns/ruby-stacktrace to spy on the ruby stack:
-parsing:
during parser, I see 60~90% time in OpenStruct
new_ostruct_member
. It seems that if Kubeclient left things as hashes and our parser accessedfoo[:bar]
orfoo["bar"]
instead offoo.bar
, we could gain a lot.parser is not main bottleneck.
container_groups is ~30% of total parsing time - OK, container_templates is ~50% - surprising!
I'd expect RAM usage to reach approximate peak during parsing, but I do see significant increase later while saving. TODO: study. (especially plausible with one huge table — like images in customer's case)
saving:
store_ids_for_new_records
.rest of time it's spread around postgresql_adapter, active_record etc...
eg. for 11000 replicators, save became 3x faster.
however, could still take hours in absolute time...