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@abes.fr
On Fri, Jan 8, 2016 at 1:13 PM, Nathanaël Blanchet <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 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
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@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
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <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ël Blanchet <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 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
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@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@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
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
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
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <awels@redhat.com> wrote: the profile and 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
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
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
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=
Von: users-bounces@ovirt.org [users-bounces@ovirt.org]" im Auftrag v= on "Nicolas Ecarnot [nicolas@ecarnot.net]=0A= Gesendet: Sonntag, 3. April 2016 21:20=0A= An: users@ovirt.org=0A= Betreff: Re: [ovirt-users] heavy webadmin=0A= =0A= Le 03/04/2016 17:13, Greg Sheremeta a =E9crit :=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--
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@ecarnot.net]=0A= Gesendet: Sonntag, 3. April 2016 21:32=0A= An: Markus Stockhausen; users@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--
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@collogia.de> wrote:
Von: Nicolas Ecarnot [nicolas@ecarnot.net] Gesendet: Sonntag, 3. April 2016 21:32 An: Markus Stockhausen; users@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
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.
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.
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@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@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@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
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
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
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <awels@redhat.com> wrote: the profile and 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com 919-741-4016
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 :
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@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@redhat.com <mailto:nsoffer@redhat.com>> wrote:
On Fri, Jan 8, 2016 at 4:42 PM, Alexander Wels <awels@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@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@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
--=20 Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com <mailto:gshereme@redhat.com> 919-741-4016 <tel:919-741-4016>
--=20 Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com <mailto:gshereme@redhat.com> 919-741-4016
_______________________________________________ Users mailing list Users@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@abes.fr --------------090604020401030504010604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <html> <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@redhat.com</a>></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@redhat.com</a></a>></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@redhat.com</a>> 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@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@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@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@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@abes.fr</a> </pre> </body> </html> --------------090604020401030504010604--
participants (7)
-
Alexander Wels -
Brett I. Holcomb -
Greg Sheremeta -
Markus Stockhausen -
Nathanaël Blanchet -
Nicolas Ecarnot -
Nir Soffer