+++ This bug is an upstream to downstream clone. The original bug is: +++ +++ bug 1388536 +++ ====================================================================== Description of problem: Currently host monitoring is updating database data inefficiently and we have seen it causes big db load for larger setups. So we need to clean up the code here and optimize database updates similarly as it has been done inside VM monitoring Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: (Originally by Martin Perina)
Adding CodeChange, for testing it is sufficient the basic sanity on db performance with host and VM statuses. With this interval to write to vds_dynamic was changed from few seconds to 1-2 per minute.
By accident change Qa contact, reverting :)
The title is 4.0.z , the target milestone is 3.6.10 - is it going to be in 3.6.10 somehow? I'd be happy to see it, although I would not wait for it.
Yes, this is 4.0.7 clone of upstream BZ1388536, once I receive all acks, I'm going to clone 3.6.10.
(In reply to rhev-integ from comment #0) > +++ This bug is an upstream to downstream clone. The original bug is: +++ > +++ bug 1388536 +++ > ====================================================================== > > Description of problem: > > Currently host monitoring is updating database data inefficiently and we > have seen it causes big db load for larger setups. So we need to clean up > the code here and optimize database updates similarly as it has been done > inside VM monitoring > > Version-Release number of selected component (if applicable): > > > How reproducible: > > > Steps to Reproduce: > 1. > 2. > 3. > > Actual results: > > > Expected results: > > > Additional info: > > (Originally by Martin Perina) Ravi, can you specify what assets profile you used ? how many hosts ? vms? SDs?
I test with 2 hosts, 4 VMs and 1 NFS storage domain on my dev env.
(In reply to Ravi Nori from comment #7) > I test with 2 hosts, 4 VMs and 1 NFS storage domain on my dev env. how did you measure the dbload? in terms of how long you monitor it ? can you specify also which table grows or in which table you saw the load?
I used break point in the code VdsDynamicDaoImpl.updateIfNeeded and saw that the vds_dynamic table was update less frequently than before this patch. Before this patch the table is updated every 3 seconds, with this patch it is updated only when there is a real change in the VdsDynamic information.
(In reply to Ravi Nori from comment #9) > I used break point in the code VdsDynamicDaoImpl.updateIfNeeded and saw that > the vds_dynamic table was update less frequently than before this patch. > Before this patch the table is updated every 3 seconds, with this patch it > is updated only when there is a real change in the VdsDynamic information. cpu utilizaion change will trigger the update?! or its more about status change ?
(In reply to Eldad Marciano from comment #10) > (In reply to Ravi Nori from comment #9) > > I used break point in the code VdsDynamicDaoImpl.updateIfNeeded and saw that > > the vds_dynamic table was update less frequently than before this patch. > > Before this patch the table is updated every 3 seconds, with this patch it > > is updated only when there is a real change in the VdsDynamic information. > > cpu utilizaion change will trigger the update?! > > or its more about status change ? Eldad - this is CodeChange - I don't see a reason for QE to test this.
(In reply to Yaniv Kaul from comment #11) > (In reply to Eldad Marciano from comment #10) > > (In reply to Ravi Nori from comment #9) > > > I used break point in the code VdsDynamicDaoImpl.updateIfNeeded and saw that > > > the vds_dynamic table was update less frequently than before this patch. > > > Before this patch the table is updated every 3 seconds, with this patch it > > > is updated only when there is a real change in the VdsDynamic information. > > > > cpu utilizaion change will trigger the update?! > > > > or its more about status change ? > > Eldad - this is CodeChange - I don't see a reason for QE to test this. OK, so is it ok to close it or move it to verify ?!
Code Change, moving to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2017-0108.html