Re: [squid-users] Cache Log Errors

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 04 Apr 2011 15:22:31 +1200

 On Sun, 3 Apr 2011 13:41:22 -0400, squid_at_sourcesystemsonline.com wrote:
> Good day,
> I have 4GB RAM install in my squid server.
> After increasing the RAM "maximum resident size" due high page faults
> and
> reconfigure squid a "WARNING: Very large
> maximum_object_size_in_memory
> settings can have negative impact on performance" was displayed.

 No, no. That setting does not affect the problem like that.

 Resident size is not something Squid can easily affect directly.
 Have a read through http://wiki.squid-cache.org/SquidFaq/SquidMemory to
 learn how Squid uses memory and what things can be adjusted to affect
 that.

 You need to ensure that when squid is not running the operating system
 says "free available memory" is a bigger number than the Squid maximum
 resident size. And that when Squid is running the amount of virtual or
 "swap" memory reported by the operating system is zero.

 More on that below. But please read that wiki page before continuing,
 the answers below will make a lot more sense when you know the
 background ideas.

>
> What is the implication of this warning, any danger?

 The setting you changed is the limit on *individual* objects stored in
 memory. The problems referred to are the swapping ones you are already
 seeing before the change. The change may make them randomly even worse
 than before.

> See below for more information and excerpts from my squid.conf
> Regards,
> Yomi.
>
>
> C:\squid\sbin>squid -n squid -k reconfigure
> 2011/04/03 17:46:15| WARNING: Very large
> maximum_object_size_in_memory
> settings
> can have negative impact on performance
>
> Status of squid Service:
> Service Type: 0x10
> Current State: 0x4
> Controls Accepted: 0x5
> Exit Code: 0
> Service Specific Exit Code: 0
> Check Point: 0
> Wait Hint: 0
>
> # MEMORY CACHE OPTIONS
>
> ---------------------------------------------------------------------------
> #Default:
> cache_mem 1024 MB

 Hmm, 4GB of RAM on the system and you are dedicating 25% of it to a RAM
 cache for Squid.

>
> #Default:
> maximum_object_size_in_memory 131072 KB

 This can at most be set to the same as cache_mem. Though generally you
 want many HTTP objects in the RAM cache.

>
> #Default:
> # memory_replacement_policy lru
>
> # DISK CACHE OPTIONS
> #
> --------------------------------------------------------------------------
> #Default:
> # cache_replacement_policy lru
>
> #Default:
> cache_dir ufs c:/squid/var/cache 40960 128 512
> cache_dir ufs d:/squid/var/cache 20480 128 512
> cache_dir ufs e:/squid/var/cache 5120 128 512
> cache_dir ufs f:/squid/var/cache 20480 128 512

 Using the rule-of-thumb 1MB/GB estimate those dir need 880 MB of memory
 for their indexes. Plus the cache_mem RAM cache. That gives up to 2GB of
 RAM consumed by Squid before any clients start connecting. More for
 traffic handling.

 Also, I believe the aufs scheme uses windows disk IO threading. You
 could possibly avoid some of the disk speed problems by changing those
 types to aufs (just a Squid restart needed to switch).

 Also check that those sizes are leaving at least 10% of the disk space
 free on each for the cache swap.state journals. If the disk is filled
 that would result in those unable to save swap.state which your shutdown
 sees.

 Also check that the disks are not being put into any kind of standby or
 hibernate mode underneath Squid. I suspect that would lead to the
 "resource unavailable" messages your logs show.

>
> #Default:
> # cache_swap_low 90
> # cache_swap_high 95

 With caches >20GB I would change that low-threshold 90 to a 94. That
 minimizes the period when the background garbage collection can drain
 speed.

 There is nothing there to indicate a box with 4GB RAM would swap badly.
 So I conclude there must be other software hogging memory and reducing
 the amount available to Squid. Removing that other software would be a
 good thing for performance.

 Amos
Received on Mon Apr 04 2011 - 03:22:36 MDT

This archive was generated by hypermail 2.2.0 : Mon Apr 04 2011 - 12:00:01 MDT