Re: Size of the squid process.

Lars.Slettjord@cc.uit.no writes:

>Hi
>
>When I came to work this morning I discovered that my squid
>process had a size of about 130 MB. It had then been running
>for 11 days. Since my server only have 128 MB memory, and
>nearly all of the swap space was gone too, I restarted the
>server.
>
>But now I have some questions about the memory usage. The
>cache was configured to use 32 MB cache_mem (I changed this
>to the default 16 MB). After the restart it loaded
>159991 objects. The Harvest cached FAQ states that "You need
>about 80 bytes of VM per object you are caching." I don't know
>if this holds for squid, but it sould give me about
>159991 * 80 = 12.2 MB of VM used. Since I reduced cache_mem to
>16 MB I sould now have a process size of about 29 MB.
>
>Just after the restart I checked with top, and the squid
>process was 30.4 MB. But it is growing again. Could someone
>explain to me how the squid cache uses memory, and how much
>it is using to what. Since I am running other services on
>the machine I'd like to keep the size of the squid process
>somewhere under 90 MB.

If you haven't already, look at your cachemgr 'info' page
Mine looks like this:

Memory usage for squid via mallinfo():
       Total space in arena: 94687 KB
       Ordinary blocks: 32019 KB 210034 blks
       Small blocks: 44364 KB 569500 blks
       Holding blocks: 0 KB 5695 blks
       Free Small blocks: 6650 KB
       Free Ordinary blocks: 11652 KB
       Total in use: 76384 KB 81%
       Total free: 18302 KB 19%

Meta Data:
       StoreEntry 246043 x 64 bytes = 15377 KB
       IPCacheEntry 971 x 88 bytes = 83 KB
       Hash link 2 x 24 bytes = 0 KB
       URL strings = 11422 KB
       Pool MemObject structures 514 x 144 bytes = 72 KB ( 70 free)
       Pool for Request structur 516 x 4380 bytes = 2207 KB ( 2121 free)
       Pool for in-memory object 6200 x 4096 bytes = 24800 KB ( 22888 free)
       Pool for disk I/O 242 x 8192 bytes = 1936 KB ( 1888 free)
       Miscellaneous = 2600 KB
       Total Accounted = 58499 KB

So first note that mallinfo() reports 94M in "arena." This is pretty
close to what 'top' says (97M).

Of that 94M, 81% (76M) is actually being used at the moment. The
rest has been freed, or pre-allocated by malloc() and never yet used.

Of the 76M in use, we can account for 58.5M (76%). There are some
calls to malloc() which we don't account for.

The 'Meta data' list gives the breakdown of where the accounted memory
has gone. 45% has gone to the StoreEntry's and URL strings. Another
42% has gone to buffers which hold objects in VM while they are being
fetched and relayed to the clients ('Pool for in-memory object').

The sizes for the 'pools' are chosen from the config parameters. In
version 1.0, these pools are somewhat "broken," but it works like
this: we keep a stack of unused pages instead of freeing the block.
For the 'in-memory object' pool, the unused stack size is 1/2 of
'cache_mem'. For the 'disk I/O' its hardcoded at 1000. For MemObject
and Request its 1/8 of your system's FD_SETSIZE value. For v1.1 it
has been fixed so the total allocated (used+unused) doesn't grow above
the chosen limits, rather than just the unused amount.

If you are looking for a way to lower your process size, first I would
recommend lowering the max object sizes in the 'http', 'ftp' and 'gopher'
config lines. You may also want to lower 'cache_mem' to suit your needs.
But if you make cache_mem too low, then some objects may not get saved
to disk if you cache encounters a relatively high-load period where many
objects are in transit at once.

Duane W.
Received on Fri Aug 09 1996 - 15:45:47 MDT