This is an odd situation that Apple thinks Parallels has a memory leak. I just purchased the new iMac 27" with dual core and 8Gig of memory. Windows XP & Windows 7 is installed and screams on this machine. HOWEVER! If you let the Mac sit idle for 1 1/2 hours in either virtual machine Windows runs very slow. Sometimes it can take up to 20 seconds to after you hit the start button for the start menu to display. And vice versa. Also shut down time is slow. If I reboot the whole Mac system its back to normal. Back left idle same thing all over again. I opened activity monitor and the CPU processes is at 100%. When first booted it is less than 1%. Apple is telling me I have to wait for a patch. Tried Fusion and it is not compatible with the new firmware in the new iMac DVD drives (Verified by Apple). Anybody have any ideas? Thanks Duke
Please, provide following information: 1. Problem Report. To make a problem report, goto Help -> Report a problem... and post its number here 2. Find process with 100% CPU load in Activity Monitor application, select it and press "Sample" button. Resulting output post here or insert in problem report.
Thank you - I have submitted to support ID 747338 Will post any responses I hear about as I am sure this will affect everyone that purchases a new iMac.
Thank you for information, but: 1. It is required to make problem report when CPU is loaded at 100%. On the screenshot from problem report I can see just that everything is fine. Please reproduce the situation with 100% load of CPU and make problem report then. 2. When you will see process in Activity Monitor that consumes near 100% of CPU, select it in Activity Monitor list and click Sample Process button it Activity Monitor and post resulting output here.
Windows XP very slow after idle It took ages to solve idle issue, but finally cracked it for my XP. Windows XP very slow after idle appears to be issue with pagefile system cache (PF Usage) taking up exessive I/O activity on the disk (writing to harddrives) due to highly fragmented pagefile.sys file. Hence no real CPU usage showing, and changing PF Usage levels may not have much effect as it is not the size of PF, it is the fragmentation of the PF (normal defragment tools do not touch this file). There is no more slowdown after I did a defragment of pagefile.sys with a tool that can actually access it (PageDefrag v2.32 By Mark Russinovich). An even simpler solution may be to set computer to clear pagefile on shutdown (I didn’t try this but probably works too - see below). The high I/O was not from a rogue program or virus. It was slow buildup in pagefile.sys file fragmentation, the disk area storing current virtual memory blocks. My pagefile.sys had something like 264,000 fragments. Virtual memory is stored in 4KB blocks, but the fragmented block pattern was taking up excessive I/O for the drive to read after computer had been in idle. During idle lots of application data is sent to pagefile rather than kept in RAM. Then when you start using applications again the computer is getting it back out of pagefile.sys: but if the pagefile.sys is highly fragmented then it can be painfully slow disk read speed. i.e. I sit there with almost nothing happening for 30 seconds, or watching webpages load almost one pixel line at a time. I defragmented pagefile.sys, but maybe it is simpler to clear the file, something like: Click Start > Click Control Panel > Click Administrative Tools > Click Local Security Policy > Click the "+" next to Local Policies > Click Security Options > Doubleclick "Shutdown: Clear Virtual Memory OR Start Registry Editor (Regedt32.exe). > Change the data value of the ClearPageFileAtShutdown value in the following registry key to a value of 1: > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management > If the value does not exist, add the following value: Value Name: ClearPageFileAtShutdown > Value Type: REG_DWORD > Value: 1 > Good luck! References: http://home.comcast.net/~SupportCD/XPMyths.html http://technet.microsoft.com/en-us/sysinternals/bb897426.aspx http://blogs.msdn.com/b/ntdebugging/archive/2007/11/27/too-much-cache.aspx