Controlling memory usage

[Anders Berg]

Thx for detailed answers Poul-Henning and Dag-Erling,

The reason Anders N. asks about this is how Squid works today. The  
squid.conf file leaves you with a option to specify how much RAM you  
wanna use for Squid. The problem is that Squid (probably because of  
old design) does not really "follow" that option. If you set 256 MB  
RAM, you can still end up using 500 MB RAM, and if you set option  
close to max memory you will for certain overflow your physical RAM  
and start swapping/die. Your answer was detailed Poul-Henning, but  
what will prevent this from happpening in Varnish? Lets say you have  
2 applications running on a Varnish box, and both use the memory  
model Varnish uses, what will happen in the long run with a lot of  
traffic? Will they both adjust themselvs to match pysical RAM, how  
would they "compete" for RAM etc? It's possible you have already  
answered that below, but how do we "limit" RAM usage?

Also I would like to mention that while at VG neither Squid or  
Varnish (it seems) have any problem dealing with I/O, the traffic  
pattern, pysical size'es of dataset's etc. make it 100% CPU bound. My  
impression is that finn.no's pattern is quite different and interesting.

A quick look on:

http://www.tns-gallup.no/index.asp? 
type=tabelno_url&did=185235&sort=uv&sort_ret=desc&UgeSelect=&path_by_id= 
/12000/12003/12077/12266&aid=12266

will show what I mean. They have "few" users and sessions, but loads  
of pageviews, also at any given time many thousand "wares" are "hot"  
for the user, not a few popular articles. This does something to mem  
usage and I/O. I am looking forward to test-run Varnish on finn.no :)
At the same time when a ware is "sold" purging becomes important :)  
Maybe not so much on finn.no today, but I can easily see auctions  
happen in the close future :)

Anders Berg

On Jul 17, 2006, at 15:53, Poul-Henning Kamp wrote:

> 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.
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-dev
>