Controlling memory usage

[Poul-Henning Kamp]

In message <20060717113114.GA76977 at totem.fix.no>, Anders Nordby writes:


Gee, you really know how to ask "simple" questions, don't you ?  :-)


>Will Varnish dynamically use RAM optimally given how much you have
>available?

That is the intent, but we implement it by letting the kernel
decide on that.

>A problem with Squid today is that it's not possible to set an upper
>limit for how much RAM it will use, and with time it can easily grow
>beyond the limits of the VM causing it to get killed (that is it
>restarts itself, losing all cache in RAM).

Yes, I've seen that one already many years ago.

Squids two-tier storage architecture where some stuff is in ram
and the rest on disk is collapsed in varnish so that it all is
on disk, but mapped into memory.

It's important to understand that we are talking about at least
three different kinds of memory of relevance:  Virtual address room,
Virtual allocated space and Virtual mapped space.

The virtual address room is the amount of memory that the program
can address and it is basically the width of the CPU: 32 or
64 bits.  On 32 bit systems, we're limited to approx 3.5 GB.  On
64bit systems it's a non-issue.  (This will limit 32bit systems
total cache capacity accordingly, but 64bit systems are no more
expensive these days).

Virtual allocated space is the varnish programs variables and
malloc(3) allocated space.  This is what is normally counted
as "programs memory use".  All of squids memory falls in this
category.  If you use the 'malloc" storage method of varnish
it also falls here.

Virtual mapped space is the backing store file which is mapped
into the varnish process address space, and this is accounted
differently than virtual allocated space.

Finally there is the concept of "resident set size" which is
the amount of actual physical RAM the process occupies
with the bits of the above two which are mapped into memory
at any one particular time.

>I take it this will not be a problem with Varnish? :-)

I hope not, but quite frankly, apart from some scientific apps I
have seen very few programs that use memory this way (yet! but after
all we have only had virtual memory for 20 years :-/ ) so the scope
for OS bugs is certainly present.

>Do you use kernel/userspace memory as needed?

Well, yes and no:  I leave it to the operating system to do so.

I think another way to answer your question is this:

Squid is written for the old UNIX/swap model before the VAX/780
computer came around: it doesn't in any sense of the word comprehend
virtual memory.  In may ways this gets in the way of efficiency.
Reading things from a file, into userland and then writing it to a
socket moves the data:

	from disk (with DMA) to kernel RAM buffer
	from kernel RAM buffer to userland RAM.
	from userland RAM to network buffer in kernel
	from network buffer in kernel to network interface (with DMA)

This is just plain waste of good cycles.

Varnish on the other hand, is written with the maximum comprehension
of virtual memory and tries to do everything it can to avoid getting
in the way of the operating systems efficient.  Varnish maps the
backing file into the process, so the above scenario cuts out
one copy already there:

	from disk (with DMA) to userland mapped memory 
	from userland mapped memory to network buffer in kernel
	from network buffer in kernel to network interface (with DMA)

And by using the sendfile(2) system call, this even gets reduced to:

	from disk (with DMA) to userland mapped memory 
	send userland mapped memory to network interface (with DMA)

(Various details left out, TCP/IP checksums in particular)

I hope this if not exactly answers your question, at least gives
you the impression that I've thought hard about it :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.