Andres Kroonmaa wrote:
> In practice idle memory is low. Even on busiest cache I've never seen idle
> memory ever reach even close to default idle limit of 50MB.
Well, there are still race conditions where the memobject can
temporarily grow huge, so don't bet on it.
> How can I say? normally its looking good:
> Memory usage for squid via mallinfo():
> Total space in arena: 313047 KB
> Ordinary blocks: 304139 KB 370623 blks
> Small blocks: 0 KB 0 blks
> Holding blocks: 20336 KB 17 blks
> Free Small blocks: 0 KB
> Free Ordinary blocks: 8907 KB
> Total in use: 324475 KB 104%
> Total free: 8907 KB 3%
> Memory accounted for:
> Total accounted: 207924 KB
The figures you need to look at for fragmentation is the total space in
arena (sbrk) and total free.
The percentage values are slightly wrong due to a minor misunderstanding
on what the four types (arena, ordinary, small, holding) stands for.
> up, I guess I'd be in trouble... Maybe dirty startups, when loading
> of storedb takes long time, memory gets fragmented alot, as StoreEntry
> objects are very longliving, and while loading them lots of other
> stuff flies by. Maybe some kind of spikes in activity cause
> fragmenting,
In 2.3 there is a accounted memory leak on dirty startups combined with
a temporary malloc overload condition causing "free ordinary blocks" to
skyrocket. Patches are available from my patch page, or as part of 2.4
> but sometimes squid size skyrockets, and stays for a long time higher
> than normal.
Have two patches for this as well.. one where certain request patterns
could lock up memory, one where certain malformed server replies could
lock up memory. Both caused the memory usage to grow and grow until the
connection was closed.
Which Squid version and patches are you running?
/Henrik
Received on Fri Oct 20 2000 - 17:34:14 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:52 MST