2:13 p.m.
Hi all,
Since I upgraded engine to 3.6, I noticed that the webadmin takes a lot
of ressources whatever is the browser. It can become very slow even for
small actions, like changing tabs or editing a vm. The browser activity
becomes intensive (100% of cpu) and the processor very hot with a
increased fan activity. I suppose javascript to be responsible of this
behaviour. Is there a way to reduce the resource allocated to the webadmin?
(This is not a weakness of my laptop which is an i7 cpu with 16GB of RAM)
--
Nathanaël Blanchet
Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet(a)abes.fr
5:29 p.m.
On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
Hi all,
Since I upgraded engine to 3.6, I noticed that the webadmin takes a lot of
ressources whatever is the browser. It can become very slow even for small
actions, like changing tabs or editing a vm. The browser activity becomes
intensive (100% of cpu) and the processor very hot with a increased fan
activity. I suppose javascript to be responsible of this behaviour. Is there
a way to reduce the resource allocated to the webadmin?
(This is not a weakness of my laptop which is an i7 cpu with 16GB of RAM)
Sounds like https://bugzilla.redhat.com/1264809
It was closed because we could not reproduce it with current versions.
I would try first to upgrade to latest 3.6 version, and if you can reproduce it,
please reopen this bug.
Alexander: can you advice on how to debug this?
Nir
5:42 p.m.
On Friday, January 08, 2016 04:29:47 PM Nir Soffer wrote:
On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet
<blanchet(a)abes.fr> wrote:
> Hi all,
>
> Since I upgraded engine to 3.6, I noticed that the webadmin takes a lot of
> ressources whatever is the browser. It can become very slow even for small
> actions, like changing tabs or editing a vm. The browser activity becomes
> intensive (100% of cpu) and the processor very hot with a increased fan
> activity. I suppose javascript to be responsible of this behaviour. Is
> there a way to reduce the resource allocated to the webadmin?
> (This is not a weakness of my laptop which is an i7 cpu with 16GB of RAM)
Sounds like https://bugzilla.redhat.com/1264809
It was closed because we could not reproduce it with current versions.
I would try first to upgrade to latest 3.6 version, and if you can reproduce
it, please reopen this bug.
Alexander: can you advice on how to debug this?
Nir
If you are willing to spend some time helping us debug that would be great as
obviously we are unable to reproduce. If you have Chrome, can you open the
development tools (ctrl-shift-i) and go to the 'Profiles' tab. That should give
you the option to 'Collect Javascript CPU Profile' among other things. Make
sure you select that, and click start. Then go in the web admin and do
something that makes your CPU spike. Let it go for a little bit doesn't have
to be long.
Go back to the CPU profiles tab and click stop. That will generate a profile and
that profile will include the percentage of CPU usage per method. It should be
sorted by percentage. If you can take a screen shot of that and give me the
exact rpm version, I can use that to de-obfuscate the method name and
hopefully get some useful information.
Thanks,
Alexander
6:41 p.m.
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <awels(a)redhat.com> wrote:
On Friday, January 08, 2016 04:29:47 PM Nir Soffer wrote:
> On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
> > Hi all,
> >
> > Since I upgraded engine to 3.6, I noticed that the webadmin takes a lot of
> > ressources whatever is the browser. It can become very slow even for small
> > actions, like changing tabs or editing a vm. The browser activity becomes
> > intensive (100% of cpu) and the processor very hot with a increased fan
> > activity. I suppose javascript to be responsible of this behaviour. Is
> > there a way to reduce the resource allocated to the webadmin?
> > (This is not a weakness of my laptop which is an i7 cpu with 16GB of RAM)
>
> Sounds like https://bugzilla.redhat.com/1264809
>
> It was closed because we could not reproduce it with current versions.
>
> I would try first to upgrade to latest 3.6 version, and if you can reproduce
> it, please reopen this bug.
>
> Alexander: can you advice on how to debug this?
>
> Nir
If you are willing to spend some time helping us debug that would be great as
obviously we are unable to reproduce. If you have Chrome, can you open the
development tools (ctrl-shift-i) and go to the 'Profiles' tab. That should give
you the option to 'Collect Javascript CPU Profile' among other things. Make
sure you select that, and click start. Then go in the web admin and do
something that makes your CPU spike. Let it go for a little bit doesn't have
to be long.
Go back to the CPU profiles tab and click stop. That will generate a profile and
that profile will include the percentage of CPU usage per method. It should be
sorted by percentage. If you can take a screen shot of that and give me the
exact rpm version, I can use that to de-obfuscate the method name and
hopefully get some useful information.
You can also save such profile to file, and attach it to the bug.
When I reorted this, this was also reproducible in Firefox, and both profiles
are attached to the bug.
Nir
6:13 p.m.
We have patches in review that should fix this in 3.6.5. The underlying
problem is a couple of JavaScript memory leaks.
Best wishes,
Greg
On Fri, Jan 8, 2016 at 10:41 AM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels
<awels(a)redhat.com> wrote:
> On Friday, January 08, 2016 04:29:47 PM Nir Soffer wrote:
>> On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet <blanchet(a)abes.fr>
wrote:
>> > Hi all,
>> >
>> > Since I upgraded engine to 3.6, I noticed that the webadmin takes a
lot of
>> > ressources whatever is the browser. It can become very slow even for
small
>> > actions, like changing tabs or editing a vm. The browser activity
becomes
>> > intensive (100% of cpu) and the processor very hot with a increased
fan
>> > activity. I suppose javascript to be responsible of this behaviour. Is
>> > there a way to reduce the resource allocated to the webadmin?
>> > (This is not a weakness of my laptop which is an i7 cpu with 16GB of
RAM)
>>
>> Sounds like https://bugzilla.redhat.com/1264809
>>
>> It was closed because we could not reproduce it with current versions.
>>
>> I would try first to upgrade to latest 3.6 version, and if you can
reproduce
>> it, please reopen this bug.
>>
>> Alexander: can you advice on how to debug this?
>>
>> Nir
>
> If you are willing to spend some time helping us debug that would be
great as
> obviously we are unable to reproduce. If you have Chrome, can you open
the
> development tools (ctrl-shift-i) and go to the 'Profiles' tab. That
should give
> you the option to 'Collect Javascript CPU Profile' among other things.
Make
> sure you select that, and click start. Then go in the web admin and do
> something that makes your CPU spike. Let it go for a little bit doesn't
have
> to be long.
>
> Go back to the CPU profiles tab and click stop. That will generate a
profile and
> that profile will include the percentage of CPU usage per method. It
should be
> sorted by percentage. If you can take a screen shot of that and give me
the
> exact rpm version, I can use that to de-obfuscate the method name and
> hopefully get some useful information.
You can also save such profile to file, and attach it to the bug.
When I reorted this, this was also reproducible in Firefox, and both
profiles
are attached to the bug.
Nir
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
10:20 p.m.
Le 03/04/2016 17:13, Greg Sheremeta a écrit :
We have patches in review that should fix this in 3.6.5. The
underlying
problem is a couple of JavaScript memory leaks.
God bless you!
Since 3.6.2 or 3.6.3, the web admin is getting close to unusable after
some minutes (Firefox or Chrome, windows or Linux).
Alex Wels helped me try to debug this, but though much time spent on
this, we failed.
In a way, I'm satisfied other people are also expressing the same
frustration about this issue, if that can help to debug.
Thank you.
--
Nicolas ECARNOT
10:25 p.m.
This is a multi-part message in MIME format.
------=_NextPartTM-000-5c9e41de-a8be-42ad-acea-436faa6e5ffe
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Von: users-bounces(a)ovirt.org [users-bounces(a)ovirt.org]&quot; im
Auftrag v=
on "Nicolas Ecarnot [nicolas(a)ecarnot.net]=0A=
Gesendet: Sonntag, 3. April 2016 21:20=0A=
An: users(a)ovirt.org=0A=
Betreff: Re: [ovirt-users] heavy webadmin=0A=
=0A=
Le 03/04/2016 17:13, Greg Sheremeta a =E9crit :=0A=
> We have patches in review that should fix this in 3.6.5. The underlying=
=0A=
> problem is a couple of JavaScript memory leaks.=0A=
=0A=
God bless you!=0A=
=0A=
Since 3.6.2 or 3.6.3, the web admin is getting close to unusable after=0A=
some minutes (Firefox or Chrome, windows or Linux).=0A=
Alex Wels helped me try to debug this, but though much time spent on=0A=
this, we failed.=0A=
In a way, I'm satisfied other people are also expressing the same=0A=
frustration about this issue, if that can help to debug.=0A=
=0A=
=0A=
First thing we do after login is to switch refresh interval to 60s.=0A=
That seems to mitigate the sluggish behaviour.=0A=
=0A=
Markus=
------=_NextPartTM-000-5c9e41de-a8be-42ad-acea-436faa6e5ffe
Content-Type: text/plain;
name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="InterScan_Disclaimer.txt"
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
------=_NextPartTM-000-5c9e41de-a8be-42ad-acea-436faa6e5ffe--
10:47 p.m.
This is a multi-part message in MIME format.
------=_NextPartTM-000-456109da-e622-4931-b253-d737fc933944
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Von: Nicolas Ecarnot [nicolas(a)ecarnot.net]=0A=
Gesendet: Sonntag, 3. April 2016 21:32=0A=
An: Markus Stockhausen; users(a)ovirt.org=0A=
Betreff: Re: AW: [ovirt-users] heavy webadmin=0A=
=0A=
Le 03/04/2016 21:25, Markus Stockhausen a =E9crit :=0A=
> switch refresh interval to 60s.=0A=
> That seems to mitigate the sluggish behaviour.=0A=
=0A=
This I read many times.=0A=
Tried it.=0A=
To no avail.=0A=
=0A=
To be more precise. It helps for me in the case that=0A=
I'm logged on via WAN (VPN).=0A=
=0A=
Markus=0A=
------=_NextPartTM-000-456109da-e622-4931-b253-d737fc933944
Content-Type: text/plain;
name="InterScan_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="InterScan_Disclaimer.txt"
****************************************************************************
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
Vorstand:
Kadir Akin
Dr. Michael Höhnerbach
Vorsitzender des Aufsichtsrates:
Hans Kristian Langva
Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.
Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln
executive board:
Kadir Akin
Dr. Michael Höhnerbach
President of the supervisory board:
Hans Kristian Langva
Registry office: district court Cologne
Register number: HRB 52 497
****************************************************************************
------=_NextPartTM-000-456109da-e622-4931-b253-d737fc933944--
12:37 a.m.
Yeah, sorry everyone. There's actually evidence that this leak goes back to
3.5. It's a nasty one.
The major memory leak is in the footer, which updates every 5 seconds by
default. Changing the refresh setting to 60 slows down the leak. But
depending on your setup, ymmv. There's also a smaller leak in bootstrap's
tooltips which hit us pretty bad, for which I've submitted a PR [
https://github.com/twbs/bootstrap/pull/19659 ]
Best wishes,
Greg
On Sun, Apr 3, 2016 at 3:47 PM, Markus Stockhausen <stockhausen(a)collogia.de>
wrote:
> Von: Nicolas Ecarnot [nicolas(a)ecarnot.net]
> Gesendet: Sonntag, 3. April 2016 21:32
> An: Markus Stockhausen; users(a)ovirt.org
> Betreff: Re: AW: [ovirt-users] heavy webadmin
>
> Le 03/04/2016 21:25, Markus Stockhausen a écrit :
> > switch refresh interval to 60s.
> > That seems to mitigate the sluggish behaviour.
>
> This I read many times.
> Tried it.
> To no avail.
To be more precise. It helps for me in the case that
I'm logged on via WAN (VPN).
Markus
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
10:30 p.m.
On Sun, 2016-04-03 at 21:20 +0200, Nicolas Ecarnot wrote:
Le 03/04/2016 17:13, Greg Sheremeta a écrit :
> We have patches in review that should fix this in 3.6.5. The
> underlying
> problem is a couple of JavaScript memory leaks.
God bless you!
Since 3.6.2 or 3.6.3, the web admin is getting close to unusable
after
some minutes (Firefox or Chrome, windows or Linux).
Alex Wels helped me try to debug this, but though much time spent on
this, we failed.
In a way, I'm satisfied other people are also expressing the same
frustration about this issue, if that can help to debug.
Thank you.
Thank you also. I'm on 3.6.4 just released version and it can take 5+
minutes to go from the welcome page to the admin login page and then
the interface is slow and frequently throws exceptions.
3:41 p.m.
On Sunday, April 03, 2016 03:30:29 PM Brett I. Holcomb wrote:
On Sun, 2016-04-03 at 21:20 +0200, Nicolas Ecarnot wrote:
> Le 03/04/2016 17:13, Greg Sheremeta a écrit :
> > We have patches in review that should fix this in 3.6.5. The
> > underlying
> > problem is a couple of JavaScript memory leaks.
>
> God bless you!
>
> Since 3.6.2 or 3.6.3, the web admin is getting close to unusable
> after
> some minutes (Firefox or Chrome, windows or Linux).
> Alex Wels helped me try to debug this, but though much time spent on
> this, we failed.
> In a way, I'm satisfied other people are also expressing the same
> frustration about this issue, if that can help to debug.
>
> Thank you.
Thank you also. I'm on 3.6.4 just released version and it can take 5+
minutes to go from the welcome page to the admin login page and then
the interface is slow and frequently throws exceptions.
Two things to check if going from the welcome page to the login page is THAT
show.
1. Make 100% sure your DNS is setup correctly (or your /etc/hosts if that is
what you use). If the engine cannot resolve itself, it will create lots of
issues.
2. If you are running hosted engine, make sure you have enough entropy, the
login page generates a couple of tokens using secure random, which eats away
at your entropy budget heavily and since hosted engine is a VM it is possible
that you don't have enough entropy. You can check your entropy level with
this:
cat /proc/sys/kernel/random/entropy_avail
There are several options for solving the entropy problem if that is the case.
1:14 a.m.
Hi everyone,
If you've experienced this issue and you're able to upgrade to 3.6.5, I'd
love to get your feedback on the responsiveness of the webadmin UI now.
Best wishes,
Greg
On Sun, Apr 3, 2016 at 11:13 AM, Greg Sheremeta <gshereme(a)redhat.com> wrote:
We have patches in review that should fix this in 3.6.5. The
underlying
problem is a couple of JavaScript memory leaks.
Best wishes,
Greg
On Fri, Jan 8, 2016 at 10:41 AM, Nir Soffer <nsoffer(a)redhat.com> wrote:
> On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <awels(a)redhat.com> wrote:
> > On Friday, January 08, 2016 04:29:47 PM Nir Soffer wrote:
> >> On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet <blanchet(a)abes.fr>
> wrote:
> >> > Hi all,
> >> >
> >> > Since I upgraded engine to 3.6, I noticed that the webadmin takes a
> lot of
> >> > ressources whatever is the browser. It can become very slow even for
> small
> >> > actions, like changing tabs or editing a vm. The browser activity
> becomes
> >> > intensive (100% of cpu) and the processor very hot with a increased
> fan
> >> > activity. I suppose javascript to be responsible of this behaviour.
> Is
> >> > there a way to reduce the resource allocated to the webadmin?
> >> > (This is not a weakness of my laptop which is an i7 cpu with 16GB of
> RAM)
> >>
> >> Sounds like https://bugzilla.redhat.com/1264809
> >>
> >> It was closed because we could not reproduce it with current versions.
> >>
> >> I would try first to upgrade to latest 3.6 version, and if you can
> reproduce
> >> it, please reopen this bug.
> >>
> >> Alexander: can you advice on how to debug this?
> >>
> >> Nir
> >
> > If you are willing to spend some time helping us debug that would be
> great as
> > obviously we are unable to reproduce. If you have Chrome, can you open
> the
> > development tools (ctrl-shift-i) and go to the 'Profiles' tab. That
> should give
> > you the option to 'Collect Javascript CPU Profile' among other things.
> Make
> > sure you select that, and click start. Then go in the web admin and do
> > something that makes your CPU spike. Let it go for a little bit doesn't
> have
> > to be long.
> >
> > Go back to the CPU profiles tab and click stop. That will generate a
> profile and
> > that profile will include the percentage of CPU usage per method. It
> should be
> > sorted by percentage. If you can take a screen shot of that and give me
> the
> > exact rpm version, I can use that to de-obfuscate the method name and
> > hopefully get some useful information.
>
> You can also save such profile to file, and attach it to the bug.
>
> When I reorted this, this was also reproducible in Firefox, and both
> profiles
> are attached to the bug.
>
> Nir
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
12:09 p.m.
This is a multi-part message in MIME format.
--------------090604020401030504010604
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Seems to be quite good!
Le 22/04/2016 00:14, Greg Sheremeta a =E9crit :
<head <meta content=3D"text/html;
charset=3Dwindows-1252"
http-equiv=3D"Content-Type"
</head <body
bgcolor=3D"#FFFFFF" text=3D"#000000" Seems
to be quite good!<br <br <div class=3D"moz-cite-prefix">Le
22/04/2016 00:14, Greg Sheremeta a
=E9crit=A0:<br </div <blockquote
cite=3D"mid:CAEReEe8h_FXWMjBFExkdLvBT6LVEVtrR2E7CqMA1ouYhH58Y8Q@mail.gmai=
l.com"
type=3D"cite" <div
dir=3D"ltr">Hi everyone,
<div><br </div <div>If you've experienced this issue and
you're able to upgrade
to 3.6.5, I'd love to get your feedback on the responsiveness
of the webadmin UI now.</div
<div><br </div <div>Best wishes,</div <div>Greg</div
<div><br </div </div
<div class=3D"gmail_extra"><br
<div class=3D"gmail_quote">On Sun, Apr 3, 2016 at 11:13 AM, Greg
Sheremeta <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:gshereme@redhat.com"
target=3D"_blank">gsher=
eme(a)redhat.com</a>&gt;</span
wrote:<br <blockquote
class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex" <div dir=3D"ltr">We have patches in
review that should fix
this in 3.6.5. The underlying problem is a couple of
JavaScript memory leaks.
<div><br </div <div>Best wishes,</div <div>Greg</div <div><br
</div </div <div class=3D"gmail_extra" <div
<div class=3D"h5"><br
<div class=3D"gmail_quote">On Fri, Jan 8, 2016 at 10:41
AM, Nir Soffer <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:nsoffer@redhat.com" target=3D"_bla=
nk"><a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:nsoffer@redhat.c=
om">nsoffer(a)redhat.com</a></a>&gt;</span wrote:<br
<blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0
.8ex;border-left:1px #ccc solid;padding-left:1ex" <div
<div>On Fri, Jan 8, 2016 at 4:42 PM, Alexander
Wels <<a moz-do-not-send=3D"true"
href=3D"mailto:awels@redhat.com"
target=3D"_blank">awels(a)redhat.com</a>&gt;
wrote:<br
> On Friday, January 08, 2016 04:29:47 PM
Nir Soffer wrote:<br
>> On Fri, Jan 8, 2016 at 1:13 PM,
Nathana=EBl Blanchet <<a
moz-do-not-send=3D"true"
href=3D"mailto:blanchet@abes.fr"
target=3D"_blank"><a
class=3D"moz-txt-link-ab=
breviated"
href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a></a>>
wrote:<br
>> > Hi all,<br
>> ><br
>> > Since I upgraded engine to 3.6,
I noticed that the webadmin takes a lot of<br >> > ressources
whatever is the
browser. It can become very slow even for
small<br
>> > actions, like changing tabs or
editing a vm. The browser activity becomes<br >> > intensive
(100% of cpu) and the
processor very hot with a increased fan<br >> > activity. I
suppose javascript
to be responsible of this behaviour. Is<br >> > there a way
to reduce the
resource allocated to the webadmin?<br >> > (This is
not a weakness of my
laptop which is an i7 cpu with 16GB of RAM)<br >><br >> Sounds like <a
moz-do-not-send=3D"true"
href=3D"https://bugzilla.redhat.com/1264809"
rel=3D"noreferrer"
target=3D"_blank"><a class=
=3D"moz-txt-link-freetext"
href=3D"https://bugzilla.redhat.com/1264809">h=
ttps://bugzilla.redhat.com/1264809</a></a><br
>><br
>> It was closed because we could not
reproduce it with current versions.<br >><br >> I would try first to
upgrade to
latest 3.6 version, and if you can reproduce<br=
>> it, please reopen
this bug.<br
>><br
>> Alexander: can you advice on how to
debug this?<br
>><br
>> Nir<br
><br >
If you are willing to spend some time
helping us debug that would be great as<br > obviously we are unable to
reproduce. If
you have Chrome, can you open the<br > development tools
(ctrl-shift-i) and go
to the 'Profiles' tab. That should give<br > you the option to
'Collect Javascript CPU
Profile' among other things. Make<br > sure you select that, and
click start.
Then go in the web admin and do<br > something that makes your
CPU spike. Let
it go for a little bit doesn't have<br > to be long.<br ><br > Go back to the CPU profiles
tab and click
stop. That will generate a profile and<br > that profile will include
the percentage
of CPU usage per method. It should be<br > sorted by percentage. If you
can take a
screen shot of that and give me the<br > exact rpm version, I can use
that to
de-obfuscate the method name and<br > hopefully get some useful
information.<br <br </div
</div You can also
save such profile to file, and attach
it to the bug.<br
<br When I reorted
this, this was also reproducible in
Firefox, and both profiles<br
are attached to the bug.<br
<span><font color=3D"#888888"><br Nir<br </font></span <div
<div>____________________________________________=
___<br Users
mailing list<br <a
moz-do-not-send=3D"true"
href=3D"mailto:Users@ovirt.org"
target=3D"_blank">Users(a)ovirt.org</a><br <a
moz-do-not-send=3D"true"
href=3D"http://lists.ovirt.org/mailman/listin=
fo/users"
rel=3D"noreferrer"
target=3D"_blank">http://l=
ists.ovirt.org/mailman/listinfo/users</a><br
</div </div </blockquote </div
<br <br
clear=3D"all"
<div><br </div </div
</div <span
class=3D"HOEnZb"><font color=3D"#888888">-- <br <div>Greg Sheremeta, MBA<br Red Hat, Inc.<br Sr. Software Engineer<br <a moz-do-not-send=3D"true"
href=3D"mailto:gshereme@redhat.com" target=3D"_blan=
k">gshereme(a)redhat.com</a><br
<a moz-do-not-send=3D"true" href=3D"tel:919-741-4016"
value=3D"+19197414016"
target=3D"_blank">919-741-40=
16</a><br </div </font></span></div </blockquote
</div <br <br clear=3D"all" <div><br
</div -- <br <div class=3D"gmail_signature">Greg
Sheremeta, MBA<br Red Hat, Inc.<br Sr. Software Engineer<br <a moz-do-not-send=3D"true"
href=3D"mailto:gshereme@redhat.com"
target=3D"_blank">gshereme(a)redhat.com</a><br 919-741-4016<br
</div </div <br
<fieldset class=3D"mimeAttachmentHeader"></fieldset <br
<pre wrap=3D"">_______________________________________________
Users mailing list
<a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:Users@ovirt.org">Use=
rs(a)ovirt.org</a <a
class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman=
/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a </pre
</blockquote <br <pre class=3D"moz-signature"
cols=3D"72">--=20
Nathana=EBl Blanchet
Supervision r=E9seau
P=F4le Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5 =09
T=E9l. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
<a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:blanchet@abes.fr">bl=
anchet(a)abes.fr</a> </pre </body </html
--------------090604020401030504010604--
Hi everyone,
If you've experienced this issue and you're able to upgrade to 3.6.5,=20
I'd love to get your feedback on the responsiveness of the webadmin UI=20
now.
Best wishes,
Greg
On Sun, Apr 3, 2016 at 11:13 AM, Greg Sheremeta <gshereme(a)redhat.com=20
<mailto:gshereme@redhat.com>> wrote:
We have patches in review that should fix this in 3.6.5. The
underlying problem is a couple of JavaScript memory leaks.
Best wishes,
Greg
On Fri, Jan 8, 2016 at 10:41 AM, Nir Soffer <nsoffer(a)redhat.com
<mailto:nsoffer@redhat.com>> wrote:
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels
<awels(a)redhat.com <mailto:awels@redhat.com>> wrote:
> On Friday, January 08, 2016 04:29:47 PM Nir Soffer wrote:
>> On Fri, Jan 8, 2016 at 1:13 PM, Nathana=EBl Blanchet
<blanchet(a)abes.fr <mailto:blanchet@abes.fr>> wrote:
>> > Hi all,
>> >> > Since I
upgraded engine to 3.6, I noticed that the
webadmin takes a lot of
>> > ressources whatever is the browser. It can become very
slow even for small
>> > actions, like changing tabs or editing a vm. The browser
activity becomes
>> > intensive (100% of cpu) and the processor very hot with a
increased fan
>> > activity. I suppose javascript to be responsible of this
behaviour. Is
>> > there a way to reduce the resource allocated to the webadm=
in?
>> > (This is not a weakness of my laptop which is
an i7 cpu
with 16GB of RAM)
> >> Sounds like
https://bugzilla.redhat.com/1264809
> >> It was closed
because we could not reproduce it with
current versions.
> >> I would try first
to upgrade to latest 3.6 version, and if
you can reproduce
>> it, please reopen this bug.
> >> Alexander: can you
advice on how to debug this?
> >> Nir
> If you are willing to
spend some time helping us debug that
would be great as
> obviously we are unable to reproduce. If you have Chrome,
can you open the
> development tools (ctrl-shift-i) and go to the 'Profiles'
tab. That should give
> you the option to 'Collect Javascript CPU Profile' among
other things. Make
> sure you select that, and click start. Then go in the web
admin and do
> something that makes your CPU spike. Let it go for a little
bit doesn't have
> to be long.
> Go back to the CPU
profiles tab and click stop. That will
generate a profile and
> that profile will include the percentage of CPU usage per
method. It should be
> sorted by percentage. If you can take a screen shot of that
and give me the
> exact rpm version, I can use that to de-obfuscate the method
name and
> hopefully get some useful information.
You can also save such profile to file, and attach it to the bu=
g.
When I reorted this, this was also reproducible in Firefox,
and both profiles
are attached to the bug.
Nir
_______________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--=20
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com <mailto:gshereme@redhat.com
919-741-4016 <tel:919-741-4016
--=20
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com <mailto:gshereme@redhat.com
919-741-4016
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--=20
Nathana=EBl Blanchet
Supervision r=E9seau
P=F4le Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5 =09
T=E9l. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet(a)abes.fr
--------------090604020401030504010604
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html
3135
days inactive
3240
days old
13 comments
7 participants
participants (7)
-
Alexander Wels -
Brett I. Holcomb -
Greg Sheremeta -
Markus Stockhausen -
Nathanaël Blanchet -
Nicolas Ecarnot -
Nir Soffer