Follow-up Comment #6, sr #108973 (project administration):
The vcs virtual machine and the underlying host is in a perpetual state of
overload. It is currently running a load of 20 for the past few days. It
had a spike to 75 a few hours ago. RAM use is reasonable. cpu utilization is
mostly negligent. This is typical when the VM can't get I/O bandwidth from
the underlying host server and so all tasks get blocked in the
ready-to-run-but-waiting-for-I/O queue.
The VM system has quite a few I/O processes stacked up in the process queues.
vcs:~# ps -ef | grep -c -e git -e cvs -e svn -e bzr -e hg
45
Since it is a virtual machine the actual system performance stats are
relatively fake so can't really be trusted. One would need to look at the
dom0 host for real stats. It would be interesting to see the I/O rates. But
I assume that 45 download processes is more than it can comfortably handle.
This VM is shared with other VMs. My general belief is that the total I/O for
the entire stack of VMs overloads the underlying host system. When that
happens even simple disk I/O in the VM is very slow. That causes everything
to queue for long times.
I will also note that the I/O bandwidth seen by the VMs is usually above 90
MB/sec. Currently on vcs hdparm reports 7.67 MB/sec after being shared with
all of the other I/O processes. I have to assume that is what each of the
above processes are seeing for disk I/O bandwidth. Which is why they are
crawling along so slowly.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/support/?108973>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
