> When I talk about the "memory ballooning daemon", I'm referring
> to the following service that runs within domain 0:
>
> /etc/init.d/squeezed
>
> The ballooning daemon is reponsible for choosing, for every VM
> running on a host, a target that lies between dynamic-min and
> dynamic-max. The ballooning daemon writes targets into XenStore.
>
> The ballooning daemon's default behaviour is to assign targets
> proportionally, as described in the previous mail. You can find
> more information about it its design here:
>
> http://wiki.xensource.com/xenwiki/squeezed
> (courtesy of Dave Scott)
Thank you! I don't know this. Interesting, can I stop it running without
damaging XCP functionality (except DMC, of course).
> The default behaviour of:
> xe vm-memory-target-set target=<x>
>
> is equivalent to:
> xe vm-memory-dynamic-range-set min=<x> max=<x>
>
> They both directly update the VM.memory-dynamic-{min,max} fields
> with the same value.
>
> See the following FAQ section for more details:
>
> http://wiki.xensource.com/xenwiki/Dynamic_Memory_Control
>
> Is there an equivalence between target mode and
> dynamic range mode?
I believe, changing xenstore value is not exactly like setting target OR
dynamic-max/dynamic-min.
I do some simple tests:
1) Set dynamic-min and dynamic-max below target value
# xenstore-ls /local/domain/36/memory
initial-reservation = "66560"
static-max = "65536"
target = "65536"
dynamic-min = "65536"
dynamic-max = "65536"
# xenstore-write /local/domain/36/memory/dynamic-min 55000
# xenstore-write /local/domain/36/memory/dynamic-max 55000
(free shows 65MiB TotalMem)
xenstore-write /local/domain/36/memory/target 55000
(free shows 55MiB TotalMem)
And even if you set target outsize dynamic-min/max, it will still works:
# xenstore-write /local/domain/36/memory/target 48000
# xenstore-ls /local/domain/36/memory
initial-reservation = "66560"
static-max = "65536"
target = "48000"
dynamic-min = "55000"
dynamic-max = "55000"
memory-offset = "0"
uncooperative = ""
... and free displays 48MiB!
That was RHEL's 2.6.18, I remember, some other version xenballoon tests
dynamic-min/max values before follow target.
...oops, it even allow to go below static-min. I believe, this happens
due lack of static-min value in xenstore. ...Interesting...
I got really strange results again (I suddenly stuck at 55MiB when I
start to raise), I'll continue to tests...
What I want to say: memory always changed by target, and dynamic-min/max
is just 'stop values' for xenballon (must to) check.
> George Shuklin replied:
> > I'd like to announce our own system named MOD (Memory on Demand)
> > wich one use xenballoon for graceful memory allocating to guest
> > machines.
> > Right now it under research and testing, but it looks really
> > good: it never steal memory to cause oom killer doing it dirty
> > job.
>
> > Main idea: we looking to memory data, calculating free memory
> > and setting target for xenballoon to preserve some amount of
> > free memory (We use static-min static-max values as borders
> > for allowed changes).
>
> I'm intrigued.
>
> Have you considered using dynamic-{min, max} for limits, rather
> than static-{min, max}? Using dynamic limits instead of static
> limits may give administrators a little more flexibility when
> constraining their VMs' memory allocations. (The current design
> of XCP allows you to change the dynamic limits while a VM is
> running, but changing the static limits requires you to reboot
> the VM.)
Well, we using external database to control daemons behavior (as part of
other features, controlled from external database), so it have it own
values to control MOD settings. But after removing squeezed, I think, we
can abandon using our values and start to use dynamic-max/min as more
native.
> > Right now we using strightforward algorithm 'preserve X MiB of
> > free memory', in future I think we can switch to some more
> > intellectual algorithm with prediction system.
> Out of interest, how do you measure "free" memory? Do you intend
> to count buffer memory as "free"?
Heh. That's was a real problem, because linux kernel eat all memory to
cache. We use internal domU agent, reporting /proc/meminfo data to
xenstore.
We use some math (primary, substraction of cache size) with hacks around
bugs in xen and -xen domU (I still research them) and calculating 'new'
memory value.
> I'd be very interested to learn more about your design.
If I persuade my boss to license code under aGPL, we will publish it as
soon, as I finish researching of xenballoon's ..em... ..a.. features.
P.S. Here funny graph of MOD activity
http://selectel.ru/photo/mod-image-1.png
X axis is time,
Y memory
dark blue line - allocated memory
magenta - used
yellow - free
cyan - swap
More detail information (sorry, Russian only):
http://habrahabr.ru/company/selectel/blog/99157
http://habrahabr.ru/blogs/cloud_computing/97998/
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
Home
