tinnycloud
2010-11-21 06:26:01 UTC
Hi:
Greeting first.
I was trying to run about 24 HVMS (currently only Linux, later will
involve Windows) on one physical server with 24GB memory, 16CPUs.
Each VM is configured with 2GB memory, and I reserved 8GB memory for
dom0.
For safety reason, only domain U's memory is allowed to balloon.
Inside domain U, I used xenballooned provide by xensource,
periodically write /proc/meminfo into xenstore in dom
0(/local/domain/did/memory/meminfo).
And in domain 0, I wrote a python script to read the meminfo, like
xen provided strategy, use Committed_AS to calculate the domain U balloon
target.
The time interval is 1 seconds.
Inside each VM, I setup a apache server for test. Well, I'd
like to say the result is not so good.
It appears that too much read/write on xenstore, when I give some of
the stress(by using ab) to guest domains,
the CPU usage of xenstore is up to 100%. Thus the monitor running in
dom0 also response quite slowly.
Also, in ab test, the Committed_AS grows very fast, reach to maxmem
in short time, but in fact the only a small amount
of memory guest really need, so I guess there should be some more to
be taken into consideration for ballooning.
For xenstore issue, I first plan to wrote a C program inside domain
U to replace xenballoond to see whether the situation
will be refined. If not, how about set up event channel directly for
domU and dom0, would it be faster?
Regards balloon strategy, I would do like this, when there are
enough memory , just fulfill the guest balloon request, and when shortage
of memory, distribute memory evenly on the guests those request
inflation.
Does anyone have better suggestion, thanks in advance.
Greeting first.
I was trying to run about 24 HVMS (currently only Linux, later will
involve Windows) on one physical server with 24GB memory, 16CPUs.
Each VM is configured with 2GB memory, and I reserved 8GB memory for
dom0.
For safety reason, only domain U's memory is allowed to balloon.
Inside domain U, I used xenballooned provide by xensource,
periodically write /proc/meminfo into xenstore in dom
0(/local/domain/did/memory/meminfo).
And in domain 0, I wrote a python script to read the meminfo, like
xen provided strategy, use Committed_AS to calculate the domain U balloon
target.
The time interval is 1 seconds.
Inside each VM, I setup a apache server for test. Well, I'd
like to say the result is not so good.
It appears that too much read/write on xenstore, when I give some of
the stress(by using ab) to guest domains,
the CPU usage of xenstore is up to 100%. Thus the monitor running in
dom0 also response quite slowly.
Also, in ab test, the Committed_AS grows very fast, reach to maxmem
in short time, but in fact the only a small amount
of memory guest really need, so I guess there should be some more to
be taken into consideration for ballooning.
For xenstore issue, I first plan to wrote a C program inside domain
U to replace xenballoond to see whether the situation
will be refined. If not, how about set up event channel directly for
domU and dom0, would it be faster?
Regards balloon strategy, I would do like this, when there are
enough memory , just fulfill the guest balloon request, and when shortage
of memory, distribute memory evenly on the guests those request
inflation.
Does anyone have better suggestion, thanks in advance.