On 2/3/20 2:46 PM, Chris Adams wrote:
Once upon a time, Marcin Sobczyk <msobczyk(a)redhat.com> said:
> Python mem profiling is hard... I already tackled the VDSM memory
> leak problem once.
> VDSM was growing, but not at a scale that Chris is describing. Tried
> out different tools,
> but got to a point, where enforcing periodic garbage collecting made
> VDSM mem usage
> constant, so the conclusion made there was no mem leaks.
Yeah, I gave it a try myself (despite not being very good at Python;
been a system admin too long so I'm all about perl :) ), and didn't get
anywhere.
> Chris, if I understood you correctly, a single machine suffices to
> reproduce your issue?
> One that acts as a host with hosted engine on it + iscsi storage?
> If so, maybe I/you could construct a VM with a reproducible
> environment and share?
> Having something like this would make investigating this issue much
> more reliable.
I don't think I've tried to reproduce it on a single machine setup. I
think I've always gone ahead and added at least a second machine (even
if there was no VM other than the engine); stopping with one to see if
it happens is a good idea. My dev cluster is actually down at the
moment (a dead UPS and nearby road/bridge construction are a bad
combination); I'll get it back online (and on a better UPS hopefully!)
today.
By "construct a VM" - do you mean building a setup inside a VM (with
nested virtualization), so everything is local? My dev cluster iSCSI
SAN is targetcli on Linux (the prod setups are all EqualLogics), so I
know how to set that up.
Yes, basically - the simpler the better. If it takes more
than one VM
than that's fine too. The no 1 priority is reproducibility. If you can
set up an env like that with virt-manager and share the XMLs
and disks with me then I will have a solid foundation to tackle
this issue.
Thank you for your help.