New Memory Poll

Discussion in 'Parallels Desktop for Mac' started by dmgwork, Jul 8, 2006.

?

Mac Memory / Parallels allocation

Poll closed Aug 22, 2006.
  1. 2 GB Mac / 1GB or more Parallels

    12.5%
  2. 2 GB Mac / 768 MB - 999 MB Parallels

    34.4%
  3. 2 GB Mac / 512 MB - 768MB Parallels

    40.6%
  4. 1.5 GB Mac / 1GB or more Parallels

    0 vote(s)
    0.0%
  5. 1.5 GBMac / 768 MB - 999 MB Parallels

    0 vote(s)
    0.0%
  6. 1.5 GB Mac / 512MB - 768 MB Parallels

    3.1%
  7. 1 GB Mac / 512 MB - 768 MB Parallels

    3.1%
  8. 1 GB Mac / 384 MB - 512 MB Parallels

    6.3%
  9. 1 GB Mac / 256 MB - 384 MB Parallels

    15.6%
  10. > 1 GB Mac / > 512 MB Parallels

    0 vote(s)
    0.0%
Multiple votes are allowed.
  1. dmgwork

    dmgwork Member

    Messages:
    81
    Based on some feedback from the last post I have modified the poll to include the amount of memory in the mac and what is allocated to Parallels
    --origianl posting
    Has anyone doen any testing to determine what is the best setting for ram in Parallels. I know they dont recomend setting it too high, and have seen a report that states at 800mb it gets much slower.

    Is this something that parallels is planning on addressing?

    If anyone has done some testing I would appreciate finding out what they have observed.
     
  2. boogie

    boogie Junior Member

    Messages:
    16
    couple things...

    1. the poll allows an individual voter to select multiple items when they vote
    2. on my 2GB mini, i'm able to allocate up to 1500MB to an individual VM
    3. likewise i'm able to allocate a maximum of 1612MB in the parallels global preference for "reserved memory limit"

    even maxing out an XP/SP2 VM at 1500MB i saw no fall off in the memory or cpu benchmarks under passmark. this confirms what i saw at lower allocation numbers of 512,768, and 1024

    in short, at 1500MB allocated to the VM, i had allocated 75% of the global physical RAM resources to a single GUEST VM and left only 25% of the global physical RAM to the HOST OS itself and whatever apps where running on the HOST

    i'm sure that if you start loading up applications in the HOST portion and parallels must compete with these other OSX apps for resources you will see degradation.

    in my own run, firing up itunes in the HOST and leaving the GUEST running worked fine for awhile, but after launching a few safari windows and browsing around i was able to get OSX locked up into a power down error where the sound was looping and the power cycle message was on the screen....not something i had ever seen before in the last several months of use with lower allocations of resources to the VM...forcing applications into a resource "corner" is asking for these type of failures.

    IMO, all of this is common sense. there is a finite amount of resources in a system for the HOST OS, HOST OS applications (like parallels), and the GUEST OS's themselves. you need to be reasonable in how you allocate these things. for example if you are using heavy, memory consumptive apps already in OS X HOST, you will not have many resources to allocate to parallels and its VM....or alternatively if you run nothing in OS X HOST but parallels, you could probably have no issues allocating up to the limit (as i saw at 1500MB allocation with no other apps running)

    virtualization isnt some magic solution that gives you something for nothing. at the end of the day you still have only so many resources and you need to be intelligent about how you allocate them.

    best of luck


    boogie
     
  3. boogie

    boogie Junior Member

    Messages:
    16
    clicked the mouse too many times apparently...duplicate content deleted
     
  4. namery

    namery Member

    Messages:
    45
    Good poll but the results are inaccurate. Say (as I am) that you have 2GB Mac and allowing Parallels 768 MB there are to options you could select:

    2 GB Mac / 512 MB - 768MB Parallels or
    2 GB Mac / 768 MB - 999 MB Parallels.
    because 768 MB is in both

    It should read 513 MB - 768 MB and 769 MB - 999 MB.

    otherwise values appear in both ranges.
     
  5. VTMac

    VTMac Pro

    Messages:
    340

    I'm not sure what you think Parallels should be addressing. The reason for Parallels getting "much slower" with >800Meg Ram allocated is because OSX is becoming starved for RAM and begins paging. There is nothing to fix. Put 4G Ram in you machine with the same setting and you'll have no problem.

    The answer for any virtualization solution (VMWare, Parallels, XEN, Q, etc.) is always to use the minimum amount of RAM that your VM needs to perform well. In my case I mainly use Windows for IE, MS Project and Visio. For me I get stellar performance allocating XP 256 meg RAM, and I have no slow downs on the OSX side. Sometimes I need to Photoshop, and in those cases I bump Ram to 768 on the Windows side. I get tremendous (unbelievable given it's virtualized) performance on Photoshop, but i notice some OSX file paging.

    RAM is the most precious resource for VM performance, configuring it wisely will depend on the precise set of processes and activities each individual user is performing. I know people who run Photoshop to do very basic activities with just 256M in an XP VM and it works great.
     
  6. unused_user_name

    unused_user_name Pro

    Messages:
    495
    We sould get the parallels people to make this sticky (HINT HINT)...

    One of the biggest re-occuring complainst I see on this forum (other then USB and sound of course) is that OS X or the VM runs sluggish. Most of the time *decreasing* the allocated RAM has helped, according to the poster.

    In a VM: more RAM != Faster performance
     
  7. dmgwork

    dmgwork Member

    Messages:
    81
    I will try lowering my ram and see if it makes a difference. I do remember that when i first installed it ( with a lower memory setting) that it use to boot much faster than it does now. I am not sure if that is due to the later versions or the additional software installations, or allocating more memory to it
     

Share This Page