Hi,
On 1/30/20 2:47 PM, Martin Perina wrote:
On Thu, Jan 30, 2020 at 2:45 PM Chris Adams <cma(a)cmadams.net
<mailto:cma@cmadams.net>> wrote:
Once upon a time, Sandro Bonazzola <sbonazzo(a)redhat.com
<mailto:sbonazzo@redhat.com>> said:
> Il giorno lun 16 dic 2019 alle ore 19:41 Chris Adams
<cma(a)cmadams.net <mailto:cma@cmadams.net>> ha
> scritto:
>
> > I've seen vdsmd leak memory (RSS increasing) for a while
(brought it up
> > on the lists and opened a BZ ticket), and never gotten
anywhere with
> > diagnosing or resolving it. I reinstalled my dev setup Friday
with
> > up-to-date CentOS 7 (minimal install) and oVirt 4.3, with a hosted
> > engine on iSCSI (multipath if it matters).
> >
>
> Adding +Martin Perina <mperina(a)redhat.com
<mailto:mperina@redhat.com>> and +Milan Zamazal
> <mzamazal(a)redhat.com <mailto:mzamazal@redhat.com>> for awareness
Is there any possibility of someone helping me look at this? I'm
seeing
the issue much worse with 4.3 - a cluster I updated to 4.3.7 two
months
ago has a host (where the hosted engine was running) where vdsmd
got to
over 20G RSS.
Marcin, any suggestions how to investigate it?
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.
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.
--
Chris Adams <cma(a)cmadams.net <mailto:cma@cmadams.net>>
--
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.