[dundee] VMWare Server 2.0

[Rick Moynihan]

2008/10/2 Lee Hughes <toxicnaan at yahoo.co.uk>:
> Thing that gets me about virtual machines is memory usage, it all well and
> good on
> a single machine (non vm)  you can have say 1GB of ram and setup 2GB of swap
> space,
> but linux seems rather lazy about claiming and reclaiming memory, if I look
> at my own
> machine I have 1GB of ram,  and currently using 787MB of swap! This would
> cause
> havoc in a virtual environment.... okay I need a memory upgrade.
>
> Until linux applications constrain their memory use , or they can be given
> hints on
> maximum or minimum  memory use then using any virtual machine technology
> that
> support paging to disk, is a no no.
>
> paging to disk is not usually a bit problem, as only one machine is
> effected, and that
> machine has already exhausted it's memory  , so a slow down is expected.
> Misbehaving
> VM's that are paging will effect performance of all vm's on that system.
>
> Take Apache for example, this always seems to grow in size, it will fork()
> more depending
> on it's load, using more memory in the process, I've never seen it release
> memory ,
> unless you restart the entire process. :-(. Obviously you can tune it, but
> be great
> if this, and other app were aware they we're being virtualised, and tuned
> their memory
> allocation accordingly..
> .
> So, perhaps applications should become more vm aware? Programmers should
> stop thinking that memory is infiite resources, and stop assuming that if
> they allocate more memory than is available then, the kernel/libc will just
> 'sort it out for them'. Memory leaks on
> one vm's app's could potential effect others..
>
> Linux still suffers from memory leaks , they get fixed, I was told once that
> the unix
> mount command leaks lots of memory, sure you only ever run it, it does it
> job
> and it quits (linux then reclaims memory) but that's not excuse for sloppy
> code.
>
> Java VM seems a bit more promising, at least you can force garbage
> collection in
> low memory situations.
>
> But what is the solution to this, large disk administrators setup up temp
> area's, where
> users can create very large working files but for a limited amount of time?
> Perhaps
> this needs to be implemented in memory management too?  Okay, mr apache you
> can
> double your memory size for but only for x amount of time.
>
> Openvz seems to stay away from virtual memory, and allows you you to
> allocate
> min and max pages, but it's rather a black magic  do with your wetting your
> finger and putting it the air.
>
> For my installed I've just pack as much ram as possible in , to avoid
> unnecessary swapping.
>
> I'd be interested about commercial vm solutions, do they have a magic bullet
> for
> memory management?

Some interesting points, but I'm not convinced that it was
virtualisation that triggered the need for applications to be more
memory aware to avoid interference with other processes.  Rather I
think we've had this very same problem since we implemented
virtual-memory and time-sharing, which must date it to around 1960!
:-)

You're right that language Runtime Environments (also called VM's but
I'll call them RE's to avoid confusion) do a lot to help improve
memory management, and Java's garbage collector is *VERY* highly
regarded.  However even the JVM (and CLR) have historically had issues
here, as garbage collection could momentarily freeze the RE.

The JVM used a "generational collection" strategy which mitigated this
for a long time, but still proved problematic, in environments which
required 'soft realtime response'.  Java 5 however saw an awesome
improvement here with the implementation of Parallel & Concurrent
Garbage Collection which kicks many of these issues firmly into touch.
 Indeed, the JVM is even supposed to be able to dynamically select a
garbage collection strategy to suit the application/environment:

http://chaoticjava.com/posts/parallel-and-concurrent-garbage-collectors/

I guess it might be nice to see this kind of approach adopted into VM
hypervisors.

The Erlang Runtime Environment, has another approach supported thanks
to it's light-weight process model.  Here processes within the RE have
separate heaps that are GC'd separately; drastically minimizing the
time a process can freeze for garbage collection:

http://prog21.dadgum.com/16.html

Speaking of Erlang, you might find this lecture interesting, where Joe
Armstrong points to many of these memory issues (at least as they
relate to forking/threading, being due to the granularity of page
table sizes in the O/S:

http://www.infoq.com/presentations/erlang-software-for-a-concurrent-world

By the way...  If you're worried about run-away processes leaking
memory then you might want to look into the process/task monitors God,
or monit:

- http://god.rubyforge.org/
- http://www.tildeslash.com/monit/doc/examples.php

They allow you to easily setup rules to restart a process if it's
memory goes over a specified value for too long.  They also do a lot
more besides!

R.