4.0 100% cpu usage in Host

ebatte

Member
LOTS of people are having serious issues with 4.0. I am one of them. I spent about an hour on the phone with tech support with a guy who did nothing but tell me to reboot and stuff like that. Useless. My problem was escalated at which point I was transferred, stayed on hold for another 20 minutes and was finally disconnected by the auto attendant because too many people were calling in. I hope Parallels have learned their lesson with this release.

Now that my rant is out of the way let me offer some insight into my problem which I have not seen mentioned on these forums:

I'm running Mac OS 10.5.5 on a MacBook Pro 17", 2.6 ghz Intel Core Duo with 4 GB RAM (about 5 months old). After installing 4.0 and migrating my XP VM I noticed 100% cpu usage by the prl_vm_app process in the Mac OS Activity Monitor. The host was almost unusable. I was unable to resolve this so I created a new VM, reinstalled XP, all service packs and the few applications I need in XP. Same problem...100% cpu usage, but this time it was not the same process it was the Parallels Desktop process.

Tweaking the VM settings had no effect. I disabled nearly everything in the configuration with no effect whatsoever.

After more investigation I have noticed that the cpu usage in the host increases the moment the guest window is opened in Parallels. This is REGARDLESS of whether the guest is running, suspended, or off. It also makes no difference what OS the guest is. I have also tried with several VMs I downloaded from Parallels. Same thing: open the guest window and cpu usage skyrockets, and stays there even when the VM is not yet even started.

Furthermore, I noted that the cpu usage in the guest is nil while the host is going crazy. This problem therefore seems to be simply with something in Parallels itself, as the guest OS or state makes no difference.

I hope this info helps someone at Parallels diagnose this problem. Maybe others of you can check to see if you have the same cpu usage in Activity Monitor, too.

Eric
 
Parallels v 4.0 high CPU usage - proposed solution

Below I have posted my configuration and a possible solution to excessive CPU usage in Parallels V 4.0.

MacBook Pro
Mac OS X 10.5.5
4 GB memory
Mac applications running:
Safari, Firefox, Mail, TextEdit, CaptureOne, Aperture, Activity Monitor

Windows Vista

Coherent Mode

Parallels v 4.0

Coherent Mode

Problem: Excessive CPU usage by Paralles software (prl_vm_app)

Parallels CPU usage 99.8%

Virtual Machine > Configure > auto > memory > 512 MB


Performance Improvement:

Stop Virtual Machine

Parallels > Preferences > Memory > Manually > 2048 MB

Virtual Machine > Configuration > Memory > 2008 MB

Re-boot computer. and re-start Virtual Machine

AVG CPU Usage

Idle CPU 20 % > 8 %

Firefox only 36 %

Outlook + Firefox 40 %

* percentages may vary on other systems

I submit that a fourfold increase in real memory allocation to Parallels resulted in a significant reduction in paging activity and freeing of cpu cycles.

Check it out!

Peter Schenk
 
Below I have posted my configuration and a possible solution to excessive CPU usage in Parallels V 4.0.

MacBook Pro
Mac OS X 10.5.5
4 GB memory
Mac applications running:
Safari, Firefox, Mail, TextEdit, CaptureOne, Aperture, Activity Monitor

Windows Vista

Coherent Mode

Parallels v 4.0

Coherent Mode

Problem: Excessive CPU usage by Paralles software (prl_vm_app)

Parallels CPU usage 99.8%

Virtual Machine > Configure > auto > memory > 512 MB


Performance Improvement:

Stop Virtual Machine

Parallels > Preferences > Memory > Manually > 2048 MB

Virtual Machine > Configuration > Memory > 2008 MB

Re-boot computer. and re-start Virtual Machine

AVG CPU Usage

Idle CPU 20 % > 8 %

Firefox only 36 %

Outlook + Firefox 40 %

* percentages may vary on other systems

I submit that a fourfold increase in real memory allocation to Parallels resulted in a significant reduction in paging activity and freeing of cpu cycles.

Check it out!

Peter Schenk

I'll have to see if I forgot to up the default memory.

I have found, however, that setting the Adaptive Hypervisor on and allowing the VM access to both CPUs (in my case) helps. One CPU being smashed 100% seems to slow the machine down even if the other is relatively idle. Have 2 CPUs at (sometimes) 80% each is better. I won't put up with it forever, but it makes Parallels useable.
 
This might decrease cpu usage for prl_vm_app, but not for the Parallels Desktop process in my case. Again, if I merely open the guest window with the guest OFF the cpu usage is instantly 100%.
 
memory allocation revision

Have revised memory allocation:

Parallels - 2048 MB

VM machine - 1024 MB

I only use one Virtual Machine, so I have no experience with 'Guest VM'

Peter Schenk
 
Peter, the Guest VM is your Virtual Machine. The Host is Mac OS and the Guest is the Virtual Machine...in this case Windows XP.

In what I describe, there is no cpu usage in Windows, but 100% cpu usage in Mac OS.
 
If this is any help below is a sample of the Parallels Desktop process taken when the Guest window is open, but the Guest is shutdown (during the 100% cpu usage time):

Sampling process 7573 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling prl_client_app (pid 7573) every 1 millisecond
Call graph:
2049 Thread_2503
2049 start
2049 start
2049 start
2049 QCoreApplication::exec()
2049 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
2049 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
2049 QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
2049 CFRunLoopRunInMode
2049 CFRunLoopRunSpecific
2049 mach_msg
2049 mach_msg_trap
2049 mach_msg_trap
2049 Thread_2603
2049 thread_start
2049 _pthread_start
2049 uuid_unpack
2049 0x13f77af5
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 select$DARWIN_EXTSN$NOCANCEL
2049 select$DARWIN_EXTSN$NOCANCEL
2049 Thread_2703
2049 thread_start
2049 _pthread_start
2049 uuid_unpack
2049 PrlApi_GetRemoteDeviceRegistration
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 uuid_unpack
2049 select$DARWIN_EXTSN$NOCANCEL
2049 select$DARWIN_EXTSN$NOCANCEL
2049 Thread_2803
2049 thread_start
2049 _pthread_start
2049 uuid_unpack
2049 PrlDisk_GetSnapshotsCount
2049 uuid_unpack
2049 pthread_cond_wait
2049 _pthread_cond_wait
2049 semaphore_wait_signal_trap
2049 semaphore_wait_signal_trap
2049 Thread_2903
2049 thread_start
2049 _pthread_start
2049 uuid_unpack
2049 PrlDisk_GetSnapshotsCount
2049 PrlDisk_GetSnapshotsCount
2049 PrlDisk_GetSnapshotsCount
2049 recvmsg$NOCANCEL$UNIX2003
2049 recvmsg$NOCANCEL$UNIX2003
2049 Thread_2a03
2049 thread_start
2049 _pthread_start
2049 QThreadPrivate::start(void*)
2041 lic_reinitialize_storage
1368 CFRunLoopRun
937 CFRunLoopRunSpecific
672 __CFRunLoopFindMode
583 CFSetGetValue
505 __CFSetFindBuckets1b
168 __CFStringHash
168 __CFStringHash
151 __CFSetFindBuckets1b
77 CFEqual
43 CFEqual
34 __CFRunLoopModeEqual
24 CFEqual
24 CFEqual
10 __CFRunLoopModeEqual
59 CFHash
59 CFHash
46 _CFHash
46 _CFHash
4 __CFRunLoopModeHash
4 __CFRunLoopModeHash
62 CFSetGetValue
8 _CFHash
8 _CFHash
4 __CFStringHash
4 __CFStringHash
3 CFHash
3 CFHash
1 __CFRunLoopModeHash
1 __CFRunLoopModeHash
82 __CFRunLoopFindMode
7 _CFRuntimeSetInstanceTypeID
7 _CFRuntimeSetInstanceTypeID
107 CFRunLoopRunSpecific
100 __spin_lock
100 __spin_lock
47 __CFRunLoopModeIsEmpty
47 __CFRunLoopModeIsEmpty
7 dyld_stub_OSSpinLockLock
7 dyld_stub_OSSpinLockLock
3 spin_unlock
3 spin_unlock
1 spin_lock
1 spin_lock
163 _CFRunLoop0
98 CFDictionaryGetValue
53 __CFDictionaryFindBuckets1a
53 __CFDictionaryFindBuckets1a
45 CFDictionaryGetValue
48 _CFRunLoop0
13 pthread_main_np
13 pthread_main_np
4 spin_unlock
4 spin_unlock
135 __spin_lock
135 __spin_lock
56 CFRunLoopRun
26 CFRunLoopGetCurrent
25 CFRunLoopGetCurrent
1 pthread_self
1 pthread_self
15 dyld_stub_OSSpinLockLock
15 dyld_stub_OSSpinLockLock
10 dyld_stub_OSSpinLockUnlock
10 dyld_stub_OSSpinLockUnlock
9 spin_unlock
9 spin_unlock
6 dyld_stub_pthread_main_np
6 dyld_stub_pthread_main_np
5 spin_lock
5 spin_lock
3 dyld_stub_pthread_self
3 dyld_stub_pthread_self
2 pthread_self
2 pthread_self
1 pthread_main_np
1 pthread_main_np
608 QWaitCondition::wakeAll()
223 __spin_lock
223 __spin_lock
95 pthread_mutex_lock
95 pthread_mutex_lock
87 pthread_mutex_unlock
87 pthread_mutex_unlock
86 pthread_cond_broadcast
86 pthread_cond_broadcast
48 QWaitCondition::wakeAll()
23 report_error(int, char const*, char const*)
23 report_error(int, char const*, char const*)
15 dyld_stub__spin_unlock
15 dyld_stub__spin_unlock
14 dyld_stub__spin_lock
14 dyld_stub__spin_lock
9 spin_lock
9 spin_lock
5 __i686.get_pc_thunk.bx
5 __i686.get_pc_thunk.bx
3 spin_unlock
3 spin_unlock
17 report_error(int, char const*, char const*)
17 report_error(int, char const*, char const*)
15 __i686.get_pc_thunk.bx
15 __i686.get_pc_thunk.bx
15 lic_reinitialize_storage
7 dyld_stub_pthread_mutex_lock
7 dyld_stub_pthread_mutex_lock
5 dyld_stub_pthread_cond_broadcast
5 dyld_stub_pthread_cond_broadcast
5 dyld_stub_pthread_mutex_unlock
5 dyld_stub_pthread_mutex_unlock
1 CFRunLoopGetCurrent
1 CFRunLoopGetCurrent
5 dyld_stub__ZN14QWaitCondition7wakeAllEv
5 dyld_stub__ZN14QWaitCondition7wakeAllEv
3 dyld_stub_CFRunLoopRun
3 dyld_stub_CFRunLoopRun

Total number in stack (recursive counted multiple, when >=5):
17 uuid_unpack
5 _pthread_start
5 thread_start

Sort by top of stack, same collapsed (when >= 5):
select$DARWIN_EXTSN$NOCANCEL 4098
mach_msg_trap 2049
recvmsg$NOCANCEL$UNIX2003 2049
semaphore_wait_signal_trap 2049
__spin_lock 458
__CFStringHash 172
__CFSetFindBuckets1b 151
CFRunLoopRunSpecific 107
pthread_mutex_lock 95
pthread_mutex_unlock 87
pthread_cond_broadcast 86
__CFRunLoopFindMode 82
CFEqual 67
CFHash 62
CFSetGetValue 62
CFRunLoopRun 56
_CFHash 54
__CFDictionaryFindBuckets1a 53
QWaitCondition::wakeAll() 48
_CFRunLoop0 48
__CFRunLoopModeIsEmpty 47
CFDictionaryGetValue 45
report_error(int, char const*, char const*) 40
CFRunLoopGetCurrent 26
dyld_stub_OSSpinLockLock 22
__i686.get_pc_thunk.bx 20
spin_unlock 19
dyld_stub__spin_unlock 15
lic_reinitialize_storage 15
spin_lock 15
dyld_stub__spin_lock 14
pthread_main_np 14
__CFRunLoopModeEqual 10
dyld_stub_OSSpinLockUnlock 10
_CFRuntimeSetInstanceTypeID 7
dyld_stub_pthread_mutex_lock 7
dyld_stub_pthread_main_np 6
__CFRunLoopModeHash 5
dyld_stub__ZN14QWaitCondition7wakeAllEv 5
dyld_stub_pthread_cond_broadcast 5
dyld_stub_pthread_mutex_unlock 5
Sample analysis of process 7573 written to file /dev/stdout
 
Possible Solution

Suggested by another user in another thread:

1. Uninstall Parallels Desktop 4.0
2. Login as another user and install PD4 while logged in as that user.
3. Log back in to your normal user account and run PD4

I did this and no longer have excessive cpu usage by prl_vm_app or the Parallels Desktop process. I should note that in my case when I reinstalled I was logged in as root, but I don't think it matters. Also, I did not have to re-import or convert my virtual machines. I am using one that I already converted to 4.0 and it works great!! Super low cpu usage!!

Good luck!

I'm going to post this as a separate thread so others will find it easier.
 
I had the same issue and tried the solution, but get "the wizard could not find a a better match..."

What do you suggest?
 
Report#19526
See Attached.

Color Key for attachment:
Green---VM Boot
Blue-----Welcome Screen
Teal-----XP Boot

Hardware:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP31.0070.B07
SMC Version: 1.16f8

PD4 Settings:
1 CPU
Chipset "0"
Memory: Default 512MB/Pref:Automatic
WinXP Virtual: Custom Size 2046-4092

Observations:
If VM needs then Host will supply--the CPU activity graphic is from the Host. The CPU activity source is described here.

VM Boot is quick, but Welcome Page shows additional activity for some time. In PD3 there was a notice that Tools was loading and don't touch. No such notice in PD4. I assume and wait for activity to subside before selecting the User in the Welcome Screen to open the Windows Desktop. Windows startup apps load better.

When CPU was set for 2, both CPUs were pegged @100% and Host/VM were non-responsive for mouse or screen changes.

Sorry, no interest in another install to try the User experiment.

I understand this issue may be different from the OP but the observations and report will hopefully be helpful.
 

Attachments

  • PD4CPUStartup.jpg
    PD4CPUStartup.jpg
    54.2 KB · Views: 5
Hi! John,

Many of us have tried ebatte's solution still having problem!

We would like to know IF THERE IS ANY PROGRESS FROM PARALLELS side!!!
 
Hi! John,

Many of us have tried ebatte's solution still having problem!

We would like to know if there is any progress from Parallels side!!!

Try ebatte solution, if problem is still over there,
While running Virtual machine submit problem report and post here ID
 
Back
Top