On 09/04/2014 01:51 PM, Juan José Pavlik Salles wrote:
Hi Jay, I do agree about 10% being too much memory in big nodes, but
right now we are using small ones (too small if you ask). These new
nodes are 16GB so if I reserve 4 Gb for the dom0 I'd be loosing 25% of
the available RAM. I was thinking about something like: if you have got
less than 32GB give 10% of it to the dom0 and If you have got more than
32GB go with 4GB for the dom0.

I'd go with something like this:

 Host RAM           dom0/reserved host RAM
 ================== ======================
 16 - 32 GB         2 GB
 32 - 64 GB         2.75 GB
 64 - 128 GB        3.50 GB
 128 - 256 GB       4.25 GB
 256+ GB            5.50 GB

If you have heavy packing of VMs (lots of tiny or small VMs), you may want to add a half GB to the above, but not much more than that, IMO)

> Maybe different environments will need
different rules, but this should work in most standar deployments I'd
say. Jay, you mentioned that big nodes running many VMs don't neet more
than 4GB of dedicated RAM, haven't you ever had any swapping situation
in that kind of scenarios?

No, not on the compute nodes, no. On the controller nodes, yes, but that's a totally different thing :)

Best,
-jay

2014-09-04 14:26 GMT-03:00 Jay Pipes <[email protected]
<mailto:[email protected]>>:

    There's not really any need for 10% in my experience. Giving
    dom0/bare metal around 3-4GB is perfectly fine for the vast majority
    of scenarios, even when there's a hundred or more VMs on the box.
    Most compute node server hardware nowadays should have 128-512GB of
    RAM available, and 4GB for the host is more than enough.

    -jay


    On 09/04/2014 12:45 PM, Juan José Pavlik Salles wrote:

        Hi Tomasz, thanks for your answer. I'll start with 10% and see what
        happens. Thanks again!


        2014-09-04 13:37 GMT-03:00 Tomasz Napierala
        <[email protected] <mailto:[email protected]>
        <mailto:tnapierala@mirantis.__com
        <mailto:[email protected]>>>:



             On 04 Sep 2014, at 18:04, Juan José Pavlik Salles
             <[email protected] <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>> wrote:

              > Hi guys, I'm running a Grizzly cloud with Ubuntu
        12.04+KVM. I'd
             like to know if there's any kind of recommended free RAM
        for the
             Hypervisor. I know there's a nova variable called "
              > reserved_host_memory_mb" but don't know what a proper
        value would be.

             Check on deployed compute node that has no running VMs, add
        some
             margin, say 10% and you should be fine. Usually compute
        nodes are
             not consuming extra memory besides VMs.

             Regards,
             --
             Tomasz 'Zen' Napierala
             Sr. OpenStack Engineer
        [email protected] <mailto:[email protected]>
        <mailto:tnapierala@mirantis.__com <mailto:[email protected]>>










        --
        Pavlik Salles Juan José
        Blog - http://viviendolared.blogspot.__com
        <http://viviendolared.blogspot.com>


        _________________________________________________
        OpenStack-operators mailing list
        OpenStack-operators@lists.__openstack.org
        <mailto:[email protected]>
        
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
        
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>


    _________________________________________________
    OpenStack-operators mailing list
    OpenStack-operators@lists.__openstack.org
    <mailto:[email protected]>
    http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>




--
Pavlik Salles Juan José
Blog - http://viviendolared.blogspot.com

_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to