Bug 456990 - oVirt is eating up too much memory and behaves very slow
oVirt is eating up too much memory and behaves very slow
Status: CLOSED NOTABUG
Product: Virtualization Tools
Classification: Community
Component: ovirt-server-suite (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Hugh Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-28 23:39 EDT by Xiaohong Wang
Modified: 2016-04-27 01:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-04 10:08:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xiaohong Wang 2008-07-28 23:39:45 EDT
Description of problem:

oVirt eating up too much memory, and makes it very slow

Version-Release number of selected component (if applicable):
oVirt 0.91-1

How reproducible:


Steps to Reproduce:
1. Install the oVirt Developer Version
2. Logging the oVirt Administration User Interface. 
3. Try to add a new virtual machine pool or do any other actions
  
Actual results:
It behaves very slow and takes too much time to finish an action

Expected results:


Additional info:
It seems that oVirt eat too much memory
----------
# top
top - 11:31:54 up 18:42,  5 users,  load average: 0.83, 0.59, 0.53
Tasks: 152 total,   2 running, 150 sleeping,   0 stopped,   0 zombie
Cpu(s): 41.4%us,  1.2%sy,  0.0%ni, 34.5%id, 22.7%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   2027444k total,  1494416k used,   533028k free,    48652k buffers
Swap:  2048276k total,     6348k used,  2041928k free,   222392k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
                                                                               
                    
 3040 root      20   0  865m 799m 1828 R 80.2 40.4 559:36.60 qemu-kvm          
                                                                               
                    
 2328 root      20   0  423m  86m 8700 S  2.9  4.4   3:46.88 Xorg              
                                                                               
                    
 2850 root      20   0  360m  28m  11m S  1.3  1.4   0:05.19 gnome-terminal    
                                                                               
                    
 3051 root      20   0  514m  38m  13m S  1.1  2.0  11:40.40 /usr/share/virt   
                                                                               
                    
 2706 root      20   0  215m 5476 4068 S  0.3  0.3   0:08.21 gnome-screensav   
                                                                               
                    
    1 root      20   0  4048  832  588 S  0.0  0.0   0:01.93 init              
                           
----------
Comment 1 Alan Pevec 2008-07-31 08:14:33 EDT
800MB is normal, appliance VM is configured with: <memory>786432</memory>
Double-check that VT is enabled in BIOS, both kvm and kvm_intel|amd kmods must
be loaded and there should be no complains from kvm in dmesg
Comment 2 Perry Myers 2008-07-31 09:46:07 EDT
Also.  Running top on the host only shows us that there is a qemu-kvm process
that is taking up a lot of processor time, but it doesn't tell us at all about
what is going on on the appliance.

Log into the appliance via ssh (username root password ovirt) and run top there
as that will give us more information about what on the appliance is taking up
the CPU.
Comment 3 Xiaohong Wang 2008-08-01 03:39:08 EDT
Finally I found that this is because the Virtualization is disabled in BIOS, so
"kvm: disabled by bios" is displayed from dmesg. After enabling VT in BIOS, I
re-check that oVirt is running normally, run top on both the host and the
appliance, no process take up a lot of CPU.
apevec and pmyers, thanks for your help.

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