On Fri, 2010-01-22 at 09:41 +0000, John Haxby wrote:

> 2010/1/22 Robert G. (Doc) Savage <[email protected]>
> 
>         I've been trying F12's vinagre as a means of remoting a
>         RHEL5.4 server's display to a central console. A full screen
>         display can be remoted with vinagre, but the VNC connection is
>         quite slow and pausey even over a Gigabit Ethernet. This
>         slowdown is not just on the remote F12 viewing console. The
>         connection is driving one of four cores on the RHEL5.4 server
>         to almost 100%, dramatically dragging performance down on its
>         local console. Here's a snapshot  of "top" several minutes
>         *after* the vinagre connection is dropped: 
>         
>                 top - 23:57:46 up 6 days,  8:02,  5 users,  load average: 
> 2.81, 2.55, 2.47
>                 Tasks: 253 total,   3 running, 250 sleeping,   0 stopped,   0 
> zombie
>                 Cpu(s): 13.2%us,  2.2%sy,  0.0%ni, 59.7%id,  0.0%wa,  0.1%hi, 
> 24.8%si,  0.0%st
>                 Mem:   8175136k total,  8135640k used,    39496k free,   
> 191424k buffers
>                 Swap:  2032212k total,      216k used,  2031996k free,  
> 6328248k cached
>                 
>                   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  
> COMMAND             
>                     9 root      39  19     0    0    0 R 99.7  0.0 213:12.23 
> ksoftirqd/2         
>                  4521 root      17   0  276m  58m  20m R 52.2  0.7 923:43.59 
> Xorg                
>                  4812 doc       15   0  316m  22m  15m S  3.0  0.3 285:21.38 
> vino-server         
>                 [snip]
>         
>         Can someone suggest a safe way to bring the load average back
>         to its "pre-vinagre" value of ~0.05. The "kill -9" command is
>         ineffective on ksoftirqd.
> 
> 
> I don't know what is causing the problem with vinagre, but it's worth
> checking the gvnc web site for update and you might want to try the
> sample gvncviewer.py to see if you get the same problem.  The problem
> might actually be with vino (to which vino-server belongs) that
> behaves badly when its connection gets dropped.
> 
> Fortunately, you can't kill ksoftirqd as it's a kernel thread (if you
> could kill it your machine would hang terminally within a very short
> time).   Try killing vino-server and that should stop it doing
> whatever it is doing to make Xorg occupy as much CPU time as ksoftirqd
> will let it.  If it doesn't, then kill Xorg as well.
> 


John,

Thank you very much. Killing vino-server allowed ksoftirqd/2 to cool.
After about 10 minutes the load average dipped below 0.10 and things now
look rather normal. I'll check out that sample gvcnviewer.py. I'm a bit
unsure just who to file a Bugzilla report with, RHEL or F12. I wonder if
both groups might work together on this since F12 is supposedly going to
be the foundation for RHEL5.

--Doc Savage
  Fairview Heights, IL

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to