Amos Jeffries wrote:
On 18.04.2012 12:46, Linda Walsh wrote:
It appears the local disk-store isn't growing over time -- so I'm
assuming it it telling
me the on-disk store isn't working right?
Yes.
Please prioritise the core dump investigation.
Please use gdb and find out what the crash is coming from. The crash and
core-dump could be what is behind those incomplete or truncated responses.
At this point I suggest updating to 3.2.0.17. There are a bunch of cache
related fixes in that release. The new cache swap.state format will
rebuild your cache_dir meta data from scratch and discard anything which
has problems visible.
---
I prioritized upgrading to the latest release and will go from there
(no need waiting time in things that may have been fixed).
If the core dumps continue with the new release, please prioritise
those. Most of the rest of what you describe may be side effects of the
crashing.
---
Will do...
http_access allow CONNECT Safe_Ports
NOTE: Dangerous. Safe_Ports includes port 1024-65535 and other ports
unsafe to permit CONNECT to. This could trivially be used as a
multi-stage spam proxy or worse.
ie a trivial DoS of "CONNECT localhost:8080 HTTP/1.1\n\n" results in
CONNECT loop until your machines port are all used up.
----
Good point, Just wanted to allow the general case of SSL/non-SSL over any of the
ports. Just tryig to get things working at this point... though have had his
config for soem time and no probs -- only connector is on my side and 'me', so
I shouldn't deny myself my own service unless I try! ;-)
hierarchy_stoplist cgi-bin ?
You can drop hierarchy_stoplist from your config for simplicity.
---
check (some of these are carry-overs from prev configs or designed should
I use it for a different config).
cache_mem 8 GB
memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA
cache_dir aufs /var/cache/squid 65535 64 64
You have multiple workers configured. AUFS does not support SMP at this
time. That could be the problem you have with SWAPFAIL, as the workers
collide altering the cache contents.
---
Wah? .. but but...how do I make use of SMP with AUFS?
If I go with uniq cache dirs that's very sub-optimal -- since I end up
with 12 separate cache areas, no? when I want to fetch something from
the catch is there coordination about what content is in which worker's cache
that will automatically invoke the correct worker? -- If so, that's cool,
but if not, then I'll reduce my hit rate by 1/N-cpus
To use this cache either wrap it in "if ${process_number} = N" tests for
the workers you want to do caching. Or add ${process_number} to the path
for each worker to get its own unique directory area.
eg:
cache_dir aufs /var/cache/squid_${process_number} 65535 64 64
or
if ${process_number} = 1
cache_dir aufs /var/cache/squid 65535 64 64
endif
--- As said above, how do I get multi-benefit with asynchronous writes
and multi core?
url_rewrite_host_header off
url_rewrite_access deny all
url_rewrite_bypass on
You do not have any re-writer or redirector configured. These
url_rewrite_* can all go.
-----
Is it harmful (it was for future 'expansion plans' -- no
rewriters yet, but was planning...)
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
This above pattern ...
====
???? above what pattern?
refresh_pattern -i \.(ico|gif|jpg|png) 0 20% 4320
ignore-no-cache ignore-private override-expire
refresh_pattern -i ^http: 0 20% 4320 ignore-no-cache
ignore-private
"private" means the contents MUST NOT be served to multiple clients.
Since you say this is a personal proxy just for you, thats okay but be
carefulif you ever open it for use by other people. Things like your
personal details embeded in same pages are cached by this.
----
Got it... I should add a comment in that area to that effect
That might be a enhancement -- like -
ignore-private-same-client
"no-cache" *actually* just means check for updates before using the
cached version. This is usually not as useful as many tutorials make it
out to be.
---
Well, dang tutorials -- I'm screwed if I follow, and if I don't! ;-)
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
... is meant to be here (second to last).
refresh_pattern . 0 20% 4320
read_ahead_gap 256 MB
Uhm... 256 MB buffering per request.... sure you want to do that?
----
I **think*** so... doesn't that mean it will buffer up to 256MB
of a request before my client is read for it?
I think of the common case where I am saving a file and it takes me
a while to find the dir to save to. I tweaked a few params in this area,
and it went from having to wait after I decided, to by the time I decided, it
was already downloaded.
Would this be responsible for that?
workers 8
Please run "squid -k parse" and fix the messages about obsolete or
changed config options.
----
*sniff* -- I thought I caught most of those...
oh well..
Thanks!
Will report back when have more info...
(just started with 3.2.17, but not all the changes to the config above...
