prl_vm_app @ 99.9% CPU on Mac OS X 10.7

I use Parallels Desktop daily to virtualize Window 7. I am running a MacBook Pro(3,1), Core 2 Duo 2.4GHz, 4GB RAM, 500GB 7.2K HD, Mac OS X 10.7.

After 3-4 hours Parallels become sluggish and nearly unusable. Dragging a window can take 3 minutes before it moves. I decided to run Activity Monitor to see if I was using too many resources. RAM usage looked okay, but the CPU utilization is maxed out. Even after I quit Parallels I have two prl_vm_app processes running and both are consuming nearly 100% of each core.

I think this is a bug. I've reinstalled Parallels and the problem persists. I have Mac Pro that I use and am not sure if the problem can be recreated there, but I'll check later.

Any thoughts?

 

Same or very similar Problem

Hi, I use a MacBook Pro and Mac OS 10.6.8 and the prl_vm_app consumes sometimes more than 100% of the CPU load in general quite high above 90%. This means my computer gets very hot, and the fans are working like crasy to cool it down. See the attached screenshot.
Any suggestions. I use the most up to date version Parallels 6

DP

 

Same here... after a while prl_vm_app is going wild

I'm running Mac OSX 10.7 on a MacBook Air, 13 inches. 3 or 4 times a day, this process goes wild and I can't do anything on my Mac while is happening. The CPU hits the roof with 100% + activity.

What's is wrong?
LP

 

Fix

You want to delete the Windows Application folder from the dock on the Apple side.

From the Parallels Desktop menu, select Virtual Machine/Configure/Options/Applications and uncheck the Show Windows applications folder in Dock. Then reboot although not necessary.

 

@wycliffe

Sorry, but I don't have a windows application folder on the dock, and "show windows applications folder in dock" was not checked in.

 

After sleep mode

I have this problem after sleep mode on my Macbook pro, have too restart Parallels.

 

Sorry but this doesn't work.

 

Problem with prl_vm_app persist

This problem with this process "prl_vm_app" has been around for a long time, at least two years, but this company Parallels doesn't seem to do anything about it. It's definitely not on the Mac side since when I shut down the VM the whole memory consumption (fan going crazy) goes away. It's so annoying that makes working with the computer unbearable. I wish there was a fix to this problem because I do like Parallels, over VirtualBox for example, haven't tried Fusion, but I may have to do that if this memory hogging problem persist. Please Parallels do something about this problem, and oh by the way, upgrading to your latest Build 6.0.12094, and Mac OS Snow Leopard Build 10.6.8 doesn't work either. I'd hate to start posting on Facebook/Twitter and all other pertinent social networks about the problem, but if that's what's going to take for Parallels to take this problem seriously then so be it.

 

Something that may help

I'm hoping that I'm not mixing up virtualization programs with this reply as i've used both Fusion and Parallels heavily and at different times over the years. That disclaimer out of the way, I used to have constant problems with my virtual machine grinding to a halt and taking up every last resource in the system. After much headache, I found that the problem always came up when I had Firefox running on the host Mac while my windows VM was also running. Killing Firefox would bring the whole system back to normal again, which was frustrating because who closes their web browser nowadays......

I gave up on virtualizing my bootcamp partition for at least a year due to this issue. I'm not sure if other browsers would interact with Parallels and cause the same problem, but it may be worth the experiment to kill your browser when the problem arises and see if that fixes it.

 

Does not occur with MacPro

I have a hunch the root cause of this issue is video-related. I have a MacPro with an ATi video board and do not experience this issue at all. However, my MacBook Pro uses an NVIDIA video chipset and I can consistently expect that within a few hours my Windows 7 Ultimate VM will go to 100% and the entire VM becomes unusable. Response can be measured in minutes rather than seconds.

I am using the exact same VM image on both the MacPro and the MacBook Pro. Same version of Parallels.

 

I am almost positive this is a video-related issue and possibly something beyond.

The VM becomes unresponsive and cannot update the screen. Closing windows causes them to artifact, if they close at all. Clicking on the Windows Start menu takes 3-5 minutes before any action occurs, and then the only thing on the screen is the User icon and not the menu.

I am trying to use Coherence with two screens and will see if this behavior happens when the VM is in window mode instead. I have a feeling that Coherence and dual-monitors is just exasperating the issue, but it definitely seems to be video-related.

 

I have more information for this thread.

I stopped using Coherence and am using my Win7 VM in a window. I've maxed out the window size on the second monitor connected to my MacBook Pro. I also have Enable 3D acceleration and Enable vertical synchronization turned off.

Right now I am not experiencing any performance issues with the VM. Normally after a few hours the VM becomes unusable.

I am confident this is a video / Coherence-related issue.

 

I'm glad it worked for you. However, I did everything you did on my XP/SP3 VM on a MacPro and pri_vm_app continued to dominate the CPU - even hitting 90%+ on occasion, although, to be fair, it settles around 15% when there are no apps running in XP.

I also have an MS-DOS VM and that also has pri_vm_app hitting the same 15% CPU. Closing down all VMs but leaving Parallels in memory shuts pri_vm_app down - not surprising.

This is very frustrating.

 

I can also see this behaviour. I have a quad-core processor on a MacBook Pro, and prl_vm_app takes as much CPU time as I assign to it: One core, 100%, two cores 200%, etc.

Also on OS X Lion v. 10.7.1, running Parallels Desktop v7

It is really annoying, as the VM becomes unusable after a while. Are there any steps the parallels people can help us make to resolve this issue?

 

A probable fix

Note for prl_vm cpu time fix:
1. shutdown or suspend your Windows VM
2. open Terminal app (/Applications/Utilities/Terminal.app)
3. perform follow commands:
sudo launchctl stop com.parallels.desktop.launchdaemon
sudo launchctl start com.parallels.desktop.launchdaemon


It worked for me with PD7 under 10.7.1

Now pro_vm CPU time is very low.

 

The problem here is that when prl_vm_app takes all that CPU the VM becomes unresponsive and all I can do is Force QUit both parallels and the process. I can't suspend or shut down the VM.

When should this be done?

@Parallels team: do you have any comments on this issue?

 

I tried the procedure suggested by hageme with Parallels 6 and Win XP. It had no effect.

I also tried using a windows view rather than Coherence. Also no effect. Pri_vm_app still jerks around 100%.

Why would I pay for Parallels 7 unless they fix this persistent problem (or at least make a comment on this thread)?

 

I too have the same problem - even going up to +137% at times.

However, I've just defragmented the virtual harddrive and it's dropped down to 14% and has kept that way for over an hour now. Perhaps this very high processing is down to jumping all over the mac harddrive disk to read the scattered bites of data all over the virtual C: drive disk?

Sure you all know how to defrag your harddrive, but if not:

Click on Start Icon, navigate to 'Computer', right-click on your Hard Disk Drive and at bottom select 'Properties', in pop-up window click on Tools tab and then click on 'Defragment Now'.

 

Interesting thought and I'm glad it worked for you.

My virtual drive is very fragmented - and remains so even after defragging it. There were many WINDOWS files which could not be moved, according to the defragmenter. I did it several times and cleared out some unwanted stuff there.

However, the pri_vm_app is still around 99% usage...

 

Sad to say that it did not work - back up to a steady 116% at the moment.... back to the drawing board.