On Fri, Oct 7, 2016 at 4:02 PM, Michal Skrivanek < [email protected]> wrote:
> > On 7 Oct 2016, at 15:28, Simone Tiraboschi <[email protected]> wrote: > > > > On Fri, Oct 7, 2016 at 3:25 PM, Michal Skrivanek < > [email protected]> wrote: > >> >> On 7 Oct 2016, at 14:59, Nir Soffer <[email protected]> wrote: >> >> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek < >> [email protected]> wrote: >> >>> >>> On 7 Oct 2016, at 14:42, Nir Soffer <[email protected]> wrote: >>> >>> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer <[email protected]> wrote: >>>> >>>>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 5, 2016 at 9:17 AM, gregor <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> did you found a solution or cause for this high CPU usage? >>>>>>> I have installed the self hosted engine on another server and there >>>>>>> is >>>>>>> no VM running but ovirt-ha-agent uses heavily the CPU. >>>>>>> >>>>>> >>>>>> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects >>>>>> over json rpc and this is CPU intensive since the client has to parse the >>>>>> yaml API specification each time it connects. >>>>>> >>>>> >>> wasn’t it suppose to be fixed to reuse the connection? Like all the >>> other clients (vdsm migration code:-) >>> >> >> This is orthogonal issue. >> >> >> Yes it is. And that’s the issue;-) >> Both are wrong, but by “fixing” the schema validation only you lose the >> motivation to fix the meaningless wasteful reconnect >> > > Yes, we are going to fix that too ( https://bugzilla.redhat.com/ > show_bug.cgi?id=1349829 ) > > > that’s great! Also al the other vdsClient uses?:-) > https://gerrit.ovirt.org/#/c/62729/ > What is that periodic one call anyway? Is there only one? Maybe we don’t > need it so much. > Currently ovirt-ha-agent is periodically reconnecting the hosted-engine storage domain and checking its status. This is already on jsonrpc. In 4.1 all the monitoring will be moved to jsonrpc. > > but it would require also https://bugzilla.redhat.com/ > show_bug.cgi?id=1376843 to be fixed. > > > This is less good. Well, worst case you can reconnect yourself, all you > need is a notification when the existing connection breaks > > > >> >> >> >>> Does schema validation matter then if there would be only one connection >>> at the start up? >>> >> >> Loading once does not help command line tools like vdsClient, >> hosted-engine and >> vdsm-tool. >> >> >> none of the other tools is using json-rpc. >> > > hosted-engine-setup is, and sooner or later we'll have to migrate also the > remaining tools since xmlrpc has been deprecated with 4.0 > > > ok. though setup is a one-time action so it’s not an issue there > > > >> >> >> Nir >> >> >>> >>> >>>>> Simone, reusing the connection is good idea anyway, but what you >>>>> describe is >>>>> a bug in the client library. The library does *not* need to load and >>>>> parse the >>>>> schema at all for sending requests to vdsm. >>>>> >>>>> The schema is only needed if you want to verify request parameters, >>>>> or provide online help, these are not needed in a client library. >>>>> >>>>> Please file an infra bug about it. >>>>> >>>> >>>> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899 >>>> >>> >>> Here is a patch that should eliminate most most of the problem: >>> https://gerrit.ovirt.org/65230 >>> >>> Would be nice if it can be tested on the system showing this problem. >>> >>> Cheers, >>> Nir >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/users > > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
