I do 99% of my work in CentOS, a Red Hat based linux, running under VMware player on a Windows XP laptop (4Gb RAM). In the office, on the wired network, it's fine. But away from the office, CentOS regularly goes into 'slow' mode where I tested it as running about a fifth normal speed (that was to compile and run a target simulation).
I can't figure out why it's running slowly when it goes into this mode - both Windows and CentOS task managers don't show anything unusual. I think it's more the CentOS side that's causing the problem - I don't normally reboot it, just closing the VMware session when I power down the laptop which just suspends CentOS. But I did try rebooting CentOS the other week - takes ages - and it did initially cure it. But later it slowed down again.
I think it's network related - if I leave CentOS in its network 'active' state after leaving the office, things like just opening a terminal window (and general file access I think) take a lot longer on the train where I don't have a connection. Setting the network connection (in CentOS) to inactive fixes it.
Narrowing it down further, it might also be to do with the (Open)VPN I use at home, although once CentOS is running slow, just closing the VPN and going offline doesn't make any difference. Neither does using a wired rather than wireless connection.
I could probably eventually work it out by experimenting, but if anyone has seen this before and knows the answer I would be extremely grateful to hear it.
Last edited by: Focus on Thu 28 Jul 11 at 08:53
|
Just found this, which doesn't really help :(
communities.vmware.com/thread/306718
|
|
What network connection has the VM got in VMWARE player? Host only? Bridged? NAT?
|
>> What network connection has the VM got in VMWARE player?
NAT
|
What sort of degradation are we talking about?
Seconds or minutes?
|
You've probably guessed why I asked about network connection. If it was bridged then I was wondering if switching IP addresses was a factor.
I wonder if it's anything to do with using VMWARE player - some sort of deliberate limitation?
|
>> You've probably guessed why I asked about network connection.
I'm flattered that you might think that, but no, I know/understand very little about networking.
>> If it was bridged then I
>> was wondering if switching IP addresses was a factor.
Just about follow that.
>> I wonder if it's anything to do with using VMWARE player - some sort of
>> deliberate limitation?
Seems unlikely, especially as it's not consistent. I think it would have been mentioned on the web somewhere if this was the case, but I haven't spotted it.
|
>> What sort of degradation are we talking about?
As mentioned above, it's about a fifth normal speed.
|
>As mentioned above, it's about a fifth normal speed.
Is the slowdown a fixed or multiple of a fixed amount each time?
ie. If the compile and run usually takes 5 minutes does it now take 5 minutes plus (N x Y) minutes?
If it's a networking timeout (eg. reverse name lookups) then it will be a multiple of the timeout value each time. Some timeouts do have a 'backoff' mechanism but you can usually spot that as well.
|
>> Some timeouts do have a 'backoff' mechanism but you
>> can usually spot that as well.
Good questions. It appears to be just an overall slowing down rather than (say) while it's waiting to read/write a file. For example, even display updates are noticeably tardy.
Would you expect the backoff mechanism you mention to be intermittent?
|
>Would you expect the backoff mechanism you mention to be intermittent?
Not really.
It sounds like you're running in graphical mode. Is there anything else running that could be hogging CPU.
Do you have 'nmon' installed?
pkgs.repoforge.org/nmon/
|
>> It sounds like you're running in graphical mode. Is there anything else running that could
>> be hogging CPU.
See OP. But I'll give nmon a go - I'm in the office at the moment so everything is ok, but I'll try it at home later.
|
Found the problem. Laptop running full speed all yesterday, but slow (~20%) this morning. Pulled out the power supply - back to full speed! Plugged it back in again - brakes on.
I'd already noticed what appears to be an intermittent problem with the (Dell) PSU I use at home, in that sometimes it doesn't recharge the battery, and that's what was happening this morning. The Windows power monitor showed it was on AC and the battery was on 90%, but it wasn't charging it.
But why this should have such a dramatic effect on the speed at which stuff runs under VMware... any ideas?
Typical times for a simulation build/run obtained using the linux time command:
AC:
34.601u 24.410s 1:26.69 68.0% 0+0k 0+0io 0pf+0w
Battery:
6.108u 4.689s 0:17.74 60.7% 0+0k 0+0io 0pf+0w
ie. 87 seconds (AC) vs. 18 seconds (battery)
|
What speed is the real processor running at when on AC vs battery? Sounds like Windows is throttling the CPU down. Just a thought.
What happens to other applications? Have you tried something that's (a) CPU intensive and (b) can be reproduced. e.g. how about running an encoding on Handbrake?
|
|
Yeah, something is kicking the speedstep in. Disable all power controls in windows and see what happens.
|
I agree about the CPU speed - the Windows/linux task monitors look pretty much the same whatever speed it's running at. Can't fiddle around much at the moment - too busy, but will try later.
The simulation build/run I gave timings for above is CPU intensive and reproducible.
|
To rule out a VMWARE issue, I'd reproduce the problem in Windows first.
At a guess, could power management be throttling the CPU and thus affecting performance?
|
VMware (CentOS) runs slow - Focusless
