> On 07 Oct 2016, at 16:10, Simone Tiraboschi <stira...@redhat.com> wrote: > > > >> On Fri, Oct 7, 2016 at 4:02 PM, Michal Skrivanek >> <michal.skriva...@redhat.com> wrote: >> >>> On 7 Oct 2016, at 15:28, Simone Tiraboschi <stira...@redhat.com> wrote: >>> >>> >>> >>> On Fri, Oct 7, 2016 at 3:25 PM, Michal Skrivanek >>> <michal.skriva...@redhat.com> wrote: >>>> >>>>> On 7 Oct 2016, at 14:59, Nir Soffer <nsof...@redhat.com> wrote: >>>>> >>>>>> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek >>>>>> <michal.skriva...@redhat.com> wrote: >>>>>> >>>>>>> On 7 Oct 2016, at 14:42, Nir Soffer <nsof...@redhat.com> wrote: >>>>>>> >>>>>>>> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi >>>>>>>> <stira...@redhat.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer <nsof...@redhat.com> >>>>>>>>> wrote: >>>>>>>>>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi >>>>>>>>>> <stira...@redhat.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Oct 5, 2016 at 9:17 AM, gregor <gregor_fo...@catrix.at> >>>>>>>>>>> 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/
Cool. It's not so important for one time actions but we need it to be able to drop xmlrpc finally, so it is important:) > >> 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. Ok. As long as it is low frequency it's ok. Just bear in mind for future that some of the vdsm calls may be heavy and impact performance, regardless the communication layer. Thanks and have a nice weekend, michal > 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 >>>>>>> Users@ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
