On Thu, 18 Aug 2011 03:19:48 +0300, Abbas Dadou wrote:
> Hi,
>
> I have squid 3.1.14 installed as tproxy, my issue is that squid is
> restarting every while with this error assertion failed:
> stmem.cc:121:
> "lowestOffset () <= target_offset"
>
> below is squid configuration.
>
> Thanks in advance for any help.
>
> Regards,
> Abbas
This occurs when squid needs to erase a portion of an object stored in
memory. After trimming if the trimmed bit is still apparently there.
A backtrace from the core produced during crash would be helpful.
Details on how to obtain one can be found at:
http://wiki.squid-cache.org/SquidFaq/BugReporting
<snip>
>
> positive_dns_ttl 2 minute
This will be artificially raising your DNS load.
> negative_dns_ttl 1 minute
>
> # And finally deny all other access to this proxy
> http_access deny all
>
> # Squid normally listens to port 3128
> http_port 3128
> http_port 3129 tproxy
>
> # We recommend you to use at least the following line.
> hierarchy_stoplist cgi-bin ?
>
> # Uncomment and adjust the following to add a disk cache directory.
>
> #cache_dir aufs /usr/local/squid/var/cache 250000 16 256
> cache_dir aufs /disk2/cache 300000 16 256
> cache_dir aufs /disk2/cache2 250000 16 256
> cache_dir aufs /disk3/cache 300000 16 256
> cache_dir aufs /disk3/cache2 250000 16 256
> cache_dir aufs /disk4/cache 300000 16 256
> cache_dir aufs /disk4/cache2 250000 16 256
>
> # Leave coredumps in the first cache dir
> coredump_dir /usr/local/squid/var/cache
> cache_log /usr/local/squid/var/logs/cache.log
> access_log /usr/local/squid/var/logs/access.log squid
> cache_store_log /usr/local/squid/var/logs/store.log
> logfile_rotate 10
> store_dir_select_algorithm least-load
> cache_mem 16384 MB
> maximum_object_size_in_memory 1 MB
> maximum_object_size 65536 KB
> cache_swap_high 90
> cache_swap_low 80
> ipcache_size 8192
> fqdncache_size 8192
> cache_replacement_policy heap LFUDA
> memory_replacement_policy heap LFUDA
> #minimum_object_size 20 KB
>
>
> # Add any of your own refresh_pattern entries above these.
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern http://.*\.windowsupdate\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://office\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://windowsupdate\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://w?xpsp[0-9]\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://w2ksp[0-9]\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://download\.microsoft\.com/ 0 80% 20160
> refresh_pattern http://download\.macromedia\.com/ 0 80% 20160
> refresh_pattern ftp://ftp\.nai\.com/ 0 80% 20160
> refresh_pattern http://ftp\.software\.ibm\.com/ 0 80% 20160
> refresh_pattern cgi-bin 1 20% 2
NP: storing and re-using objects which are clearly dynamic and even
more clearly still using the 20th century style of cgi-bin coding is a
bad idea. Note that this pattern ONLY gets tested for use when there are
NO details provided by the script indicating safe caching times. The
RFCs go out of their way to make an explicit statement that these type
of objects MUST NOT be cached due to their highly unsafe side effects.
Note that SHTML, ASP, PHP, PY, PL scripts are modern enough that their
server engines produce caching control information by default these
days.
> refresh_pattern \.asp$ 1 20% 2
> refresh_pattern \.acgi$ 1 20% 2
> refresh_pattern \.cgi$ 1 20% 2
> refresh_pattern \.pl$ 1 20% 2
> refresh_pattern \.shtml$ 1 20% 2
> refresh_pattern \.php3$ 1 20% 2
> refresh_pattern \? 1 20% 2
> refresh_pattern \.gif$ 0 90% 2880
> refresh_pattern \.jpg$ 0 90% 2880
> refresh_pattern \.jpeg$ 0 90% 2880
> refresh_pattern \.png$ 0 90% 2880
> refresh_pattern \.bom\.gov\.au 0 20% 2880
> refresh_pattern \.html$ 0 50% 2880
> refresh_pattern \.htm$ 0 50% 2880
> refresh_pattern \.php$ 0 50% 2880
> refresh_pattern \.class$ 0 90% 2880
> refresh_pattern \.zip$ 0 90% 2880
> refresh_pattern \.jpeg$ 0 90% 2880
> refresh_pattern \.mid$ 0 90% 14400
> refresh_pattern \.shtml$ 0 50% 2880
> refresh_pattern \.exe$ 0 90% 14400
> refresh_pattern \.msi$ 0 90% 14400
> refresh_pattern \.thm$ 0 90% 2880
> refresh_pattern \.wav$ 0 90% 14400
> refresh_pattern \.txt$ 0 90% 2880
> refresh_pattern \.cab$ 0 90% 2880
> refresh_pattern \.php$ 0 50% 2880
> refresh_pattern \.au$ 0 90% 14400
> refresh_pattern \.mov$ 0 90% 14400
> refresh_pattern \.xbm$ 0 90% 2880
> refresh_pattern \.ram$ 0 90% 2880
> refresh_pattern \.avi$ 0 90% 14400
> refresh_pattern \.chtml$ 0 50% 2880
> refresh_pattern \.thb$ 0 90% 2880
> refresh_pattern \.dcr$ 0 90% 2880
> refresh_pattern \.bmp$ 0 90% 2880
> refresh_pattern \.phtml$ 0 50% 2880
> refresh_pattern \.mpg$ 0 90% 14400
> refresh_pattern \.pdf$ 0 90% 2880
> refresh_pattern \.art$ 0 90% 2880
> refresh_pattern \.swf$ 0 90% 2880
> refresh_pattern \.mp3$ 0 90% 14400
> refresh_pattern \.ra$ 0 90% 2880
> refresh_pattern \.spl$ 0 90% 2880
> refresh_pattern \.viv$ 0 90% 2880
> refresh_pattern \.doc$ 0 90% 2880
> refresh_pattern \.gz$ 0 90% 2880
> refresh_pattern \.Z$ 0 90% 2880
> refresh_pattern \.tgz$ 0 90% 2880
> refresh_pattern \.tar$ 0 90% 2880
> refresh_pattern \.vrm$ 0 90% 2880
> refresh_pattern \.vrml$ 0 90% 2880
> refresh_pattern \.aif$ 0 90% 2880
> refresh_pattern \.aifc$ 0 90% 2880
> refresh_pattern \.aiff$ 0 90% 2880
> refresh_pattern \.arj$ 0 90% 2880
> refresh_pattern \.c$ 0 90% 2880
> refresh_pattern \.cpt$ 0 90% 2880
> refresh_pattern \.dir$ 0 90% 2880
> refresh_pattern \.dxr$ 0 90% 2880
> refresh_pattern \.hqx$ 0 90% 2880
> refresh_pattern \.jpe$ 0 90% 2880
> refresh_pattern \.lha$ 0 90% 2880
Please for your clients behalf optimize/reduce these patterns with
duplicate min/pct/max values down to a \.(a|b|c|d)$ style pattern. The
entire set of refresh_pattern lines is checked one-by-one on every
single refresh check.
<snip>
Amos
Received on Thu Aug 18 2011 - 01:51:42 MDT
This archive was generated by hypermail 2.2.0 : Thu Aug 18 2011 - 12:00:04 MDT