Bug 657847 - Increasing sluggishness and high CPU usage of virt-manager when interacting with a VM with gtk-vnc 0.4.2+
Summary: Increasing sluggishness and high CPU usage of virt-manager when interacting w...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk-vnc
Version: 14
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 659455 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-28 12:56 UTC by Howard Ning
Modified: 2011-01-05 18:12 UTC (History)
22 users (show)

Fixed In Version: gtk-vnc-0.4.2-4.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-17 20:25:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
RFC connection: unref GSource after usage (1.58 KB, patch)
2010-12-06 19:04 UTC, Marc-Andre Lureau
no flags Details | Diff

Description Howard Ning 2010-11-28 12:56:20 UTC
Description of problem:
After the update, the virt-manager's VNC became extreme slow and laggy. The normal qemu's SDL and tightvnc is still working well.

Version-Release number of selected component (if applicable):
1.9.1-3.fc14.x86_64

How reproducible:
Run a vm of fedora in virt-manager. The screen is very laggy when you drag a window.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Scott Dowdle 2010-12-01 18:24:16 UTC
I to experience this.  I tried changing from the Video model from cirrus to vga but that didn't help at all.

I think it is important to quantify the problem.  Laggy for me is when in the text console (runlevel 3), screen refreshes when the screen is full of text... you can actually see it redraw each line... and that takes about 2-3 seconds to advance a single line.  Imagine the kernel boot output (when graphical boot is off) taking several minutes just for the line by line screen refresh.

I believe updating to the recently released tigervnc update will fix this problem.  I just did and it seems to have made the problem go away.  I didn't have to reboot or restart the VM either.  I just exited from virt-manager, opened it up again and opened up a console and it was back to normal speed.

So Howard, upgrade to the following versions and see if it helps:

tigervnc-1.0.90-0.22.20100813svn4123.fc14.1.x86_64
tigervnc-license-1.0.90-0.22.20100813svn4123.fc14.1.noarch
tigervnc-server-minimal-1.0.90-0.22.20100813svn4123.fc14.1.x86_64
tigervnc-server-module-1.0.90-0.22.20100813svn4123.fc14.1.x86_64

Oddly the "tigervnc-license" package contains a directory with a single file in it and it is a copy of the GPL v2 license.  Do we *REALLY* need a separate package for the single file that is the GPL v2 license?  Ok, this isn't the proper place to mention this but I just noticed it as I was preping this post.

[root@scott ~]# rpm -ql tigervnc-license
/usr/share/doc/tigervnc-license-1.0.90
/usr/share/doc/tigervnc-license-1.0.90/LICENCE.TXT

Comment 2 Scott Dowdle 2010-12-01 21:43:43 UTC
Ignore my previous comment... upgrading to the newer tigervnc did NOT fix the problem.

Using virt-manager more and more today I've noticed that shortly after running virt-manager it will render gtk-vnc display windows reasonably well but after running it over time... its performance degrades and degrades until it starts to crawl.  This slowdown is not only obvious in the VM area of the display but also in the drop-down menus of the VM display app itself.

I've noticed that closing the VM display window, existing virt-manager and then starting virt-manager up again seems to resolve the issue again... for a while... so there is something odd still going on.  I really don't know the source of the slowdown but since virt-manager (haven't tried virt-viewer yet) is where I'm noticing the issue, it seems reasonable to file against it.

Just to clarify the machine isn't performing poorly just the graphical connection to it is.  If I access the VM from other methods such as ssh, the machine performs fine... it is just the GUI access to it that slows down over time.

Comment 3 Scott Dowdle 2010-12-01 21:47:10 UTC
Wow, have I really not given any specifics?  I guess now.

I'm on a Fedora 14 x86_64 system with everything updated as of today.

gtk-vnc-python-0.4.2-1.fc14.x86_64
kernel-2.6.35.6-48.fc14.x86_64
libvirt-0.8.3-2.fc14.x86_64
qemu-kvm-0.13.0-1.fc14.x86_64
virt-manager-0.8.5-1.fc14.noarch

Anything else troubleshooters might want to know about, just ask.

Comment 4 Howard Ning 2010-12-01 21:57:58 UTC
I think tigervnc-license is 99% unnecrssary. Just add this file to %doc to both client and server package.

Comment 5 William Lovaton 2010-12-02 03:55:23 UTC
I'm seeing this problem too and it's very annoying.

Fedora 13 was really fast moving windows around in the guest but now with Fedora 14 it is terribly slow.

Is there any idea about why this is? the usability is really bad. I have noticed this problem in all kinds of hardware: Intel Core 1 Duo 32 bit, Intel Core 2 Quad 64 bit and Intel Core i7 64 bit.  All of them are very slow in the GUI but, as Scott said in comment #2, the guest seems to be performing fine in other areas.

Right now my main home computer is running F13 32 bit with an Intel Core i3 and the performance is really good.  I'm not willing to upgrade to F14 until this problem is figured out.

Thanks.

Comment 6 William Lovaton 2010-12-02 04:15:14 UTC
BTW, why is this filed against xorg-x11-server? I just made a few tests and connecting to the virtual machine using "vncviewer 127.0.0.1" from the command line seems to work better although it's not perfect yet.

Using virt-manager it's very slow and connecting through vinagre is just as bad.

Does that tell anything?

Besides, I just noted that booting F14 guest under F14 host is really slow.  In Fedora 13 it booted almost instantly.

Comment 7 Scott Dowdle 2010-12-02 20:31:52 UTC
Wow, you are right... this bug is filed against xorg-x11-server.  I found it doing a bugzilla search for virt-manager and mistakenly thought it was filed against that.  Whoever has the power to refile it should do so.

BTW, there were some updates today including gtk-vnc, gvnc, and gtk-vnc-python.  I just installed them so I haven't had a chance to see if they make any difference.  I hope so.

Comment 8 Adam Williamson 2010-12-02 20:54:16 UTC
*** Bug 659455 has been marked as a duplicate of this bug. ***

Comment 9 Adam Williamson 2010-12-02 20:56:13 UTC
re-assigning to gtk-vnc and adding Cole to CC. The recent gtk-vnc update fixes the text issue (bug #657542) but not the general sluggishness. I'll see if downgrading to 0.4.1 avoids the general sluggishness soon.

Comment 10 Adam Williamson 2010-12-02 21:33:36 UTC
indeed, downgrading gtk-vnc seems to fix this. with a rebuilt gtk-vnc-0.4.1-9.fc15.x86_64 , CPU usage of virt-manager doesn't go above 5% while wiggling a cursor around inside a VM, and the sluggishness is not evident. So this is a regression from gtk-vnc 0.4.1 to 0.4.2.

Comment 11 William Lovaton 2010-12-03 01:50:48 UTC
Great news, I'll see if I can downgrade that package in F14.

I was wondering if the performance work done for Fedora 14 in libjpeg-turbo had anything to do with this.  This new library was supposed to improve VNC performance too but I thought that for some reason it regressed.

I guess the old version of gtk-vnc still links against libjpeg-turbo so the problem might be limited just to the new version of gtk-vnc.

Unless... I have the feeling that Fedora 14 GUI is not as responsive as F13, I can see how GDM draws up and the KMS to Xorg transition just before GDM starts feels slower and clumsy as well.

Comment 12 Adam Williamson 2010-12-03 02:06:23 UTC
no, it's not to do with that. the rebuilt gtk-vnc I'm using will be linked against libjpeg-turbo, since I built it fresh. There were more extensive changes in gtk-vnc between 0.4.1 and 0.4.2 - see https://bugzilla.redhat.com/show_bug.cgi?id=657542 for some info on them.

Comment 13 Daniel Berrangé 2010-12-06 10:57:54 UTC
GTK-VNC doesn't use libjpeg directly, it uses GdkPixbuf which loads libjpeg as a module, so if you had it installed you should already have been using it. In any case I believe that is unrelated to the performance issues.

The point at which the performance problems occurs coincides with a change in the way client<->X sever rendering is done. The note that it becomes more sluggish over time suggests perhaps a resource leak.

Comment 14 Adam Williamson 2010-12-06 16:34:56 UTC
anything else you need, Dan? this should be easy to reproduce - just set up a VM on F14 or Rawhide and try it :) thanks for looking at it.

Comment 15 Marc-Andre Lureau 2010-12-06 19:04:42 UTC
Created attachment 465043 [details]
RFC connection: unref GSource after usage

this patch works fine in spice-gtk. briefly tested with gtk-vnc.

Comment 16 Stefan Becker 2010-12-07 13:16:18 UTC
Me too. Highly annoying...

Trying to downgrade gtk-vnc first.

Comment 17 Christine Caulfield 2010-12-09 16:30:29 UTC
I had this problem too, and downgrading gtk-vnc (with some dependencies) works for me.

Comment 18 tessiof 2010-12-12 01:05:49 UTC
Same problem here! Downgrading to gtk-vnc-0.4.1, gtk-vnc-python-0.4.1 and gvnc-0.4.1 seams to solve the problem..

Comment 19 tessiof 2010-12-12 02:41:26 UTC
But now my "/" key (abnt2 keyboard) don't work within virt-manager vlc console.. o.O

Comment 20 Richard W.M. Jones 2010-12-12 09:42:53 UTC
(In reply to comment #19)
> But now my "/" key (abnt2 keyboard) don't work within virt-manager vlc
> console.. o.O

If it's a separate bug, please open a separate bug report for it.
This is not a discussion forum.  In this case I think you need to
look at bug 636907.

Comment 21 Jerry James 2010-12-13 21:25:01 UTC
I have been running with the patch from comment 15 for a couple of hours now, with no sign of a slowdown.  Before, it would become sluggish after only a few minutes.  Thanks, Marc-Andre!

Comment 22 Adam Williamson 2010-12-14 11:06:02 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 23 Adam Williamson 2010-12-14 11:24:37 UTC
I just tested Marc's patch here. It's a bit hard as I'm on a different machine from the one I usually use; this one's *very* fast and the performance isn't that bad even without the patch. With Marc's patch there's still elevated resource use on interaction, but it seems a bit lower than without the patch, and performance does feel a bit better. But again, hard to be sure, with this system.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 24 Adam Williamson 2010-12-14 11:46:15 UTC
just tested 0.4.1-9 on this machine and it seems to perform about the same as the patched 0.4.2, so as far as I can tell, the patch is doing the job.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 25 Daniel Berrangé 2010-12-14 13:02:43 UTC
While the patch in comment #15 is fixing clear bugs, it did not originally look like it had any performance implications betweeen the 0.4.1 and 0.4.2 releases. Closer inspection however reveals that it does touch an important codepath which changed between these releases, so does provide a credible explanation for the performance problems.

Patch incorporated upstream

http://git.gnome.org/browse/gtk-vnc/commit/?id=968968c9cf705f5bc96764399ea17a27a454c1c5

Comment 26 Fedora Update System 2010-12-14 13:04:23 UTC
gtk-vnc-0.4.2-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/gtk-vnc-0.4.2-4.fc14

Comment 27 Fedora Update System 2010-12-15 08:54:14 UTC
gtk-vnc-0.4.2-4.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gtk-vnc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gtk-vnc-0.4.2-4.fc14

Comment 28 Michael J. Chudobiak 2010-12-15 14:51:36 UTC
I still experience bouts of sluggishness with gtk-vnc-0.4.2-4.fc14.x86_64 installed (although I thought it was OK at first - it seems to be erratic).

I'm using vinagre to access my VM.

It is much, much faster using the tightvnc viewer.

I'm a little confused about how yum reports dependencies: it shows an earlier version of gtk-vnc, even though the latest is installed. Is that normal?


[root@xena Desktop]# rpm -qa | grep gtk-vnc
gtk-vnc-0.4.2-4.fc14.x86_64 (<-- LATEST)
gtk-vnc-python-0.4.2-3.fc14.x86_64

[root@xena Desktop]# yum deplist vinagre | grep vnc
  dependency: libgtk-vnc-1.0.so.0()(64bit)
   provider: gtk-vnc.x86_64 0.4.1-6.fc14
   provider: gtk-vnc.x86_64 0.4.2-3.fc14 (<-- NOT LATEST)

- Mike

Comment 29 Michael J. Chudobiak 2010-12-15 15:04:38 UTC
Sorry, typo: I should have said tigervnc is faster (not tightvnc).

Comment 30 Fedora Update System 2010-12-17 20:25:49 UTC
gtk-vnc-0.4.2-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 31 Mike Hinz 2010-12-17 22:38:53 UTC
I installed gtk-vnc-0.4.2-4.fc14 from updates-testing a couple of days ago.  I can definitely say that this has made the video performance better, but there is still an issue for VMs that have been running for some time.  For example, I started a VM with WinXP installed this morning and after about 8 hours, the video performance has markedly deteriorated, although much less than prior to the update to the latest gtk-vnc.  

The video performance of the VM can be immediately restored to as good as F13 simply by closing Virt-Manager and restarting it.  

It also seems to me that TOP reports increasing %CPU for python as time goes by and restarting Virt-Manager seems to take the python %CPU right back down.

FYI....Mike

Comment 32 Mike Hinz 2010-12-18 14:02:35 UTC
I installed gtk-vnc-0.4.2-4.fc14 from updates-testing a couple of days ago.  I can definitely say that this has made the video performance better, but there is still an issue for VMs that have been running for some time.  For example, I started a VM with WinXP installed this morning and after about 8 hours, the video performance has markedly deteriorated, although much less than prior to the update to the latest gtk-vnc.  

The video performance of the VM can be immediately restored to as good as F13 simply by closing Virt-Manager and restarting it.  

It also seems to me that TOP reports increasing %CPU for python as time goes by and restarting Virt-Manager seems to take the python %CPU right back down.

FYI....Mike

Comment 33 Ari Tilli 2011-01-05 14:57:37 UTC
I have gtk-vnc-0.4.2-4.fc14.x86_64 installed. 

I use first NX-connection from xp to Fedora FC14, and inside Fedora I run
virt-manager with vnc connections to W2k quests. 

For this combination this bug is still valid, since the end-result is 
totally unusable vnc-connections (moving a window lasts 30-60 secs).

Using /usr/bin/vncviewer inside the same NX-session however works just fine (with default options). I'll probably open a new bug for this exotic scenario since I can not reopen this one.

Comment 34 Adam Williamson 2011-01-05 18:12:10 UTC
please do. the bug we tracked in this report is fixed. please open new bugs for remaining poor performance scenarios. thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers


Note You need to log in before you can comment on or make changes to this bug.