Hello,
Thanks for all replies.
I've got a good hard disk, i've been checking that and haven't found any
problems or seen any error msgs in my logs.
I've adjusted my high cache size from 100% to 95% but i'm starting to
look at is squid purging oldest items from my cache? It seems like when the
cache gets full or nearly so i start having this issue?
As for my pornography and spyware rejection files they are each a
considerable size, they are lists of sites i don't want visited, downloaded,
or to have anything to do with. If there's a way to speed this up i'm all
for it.
Thanks.
Dave.
----- Original Message -----
From: "Tek Bahadur Limbu" <teklimbu@xxxxxxxxxxxx>
To: "Dave" <dmehler26@xxxxxxxxxx>
Cc: <squid-users@xxxxxxxxxxxxxxx>
Sent: Tuesday, June 26, 2007 4:14 AM
Subject: Re: FreeBSD Squid timeout issue
Dave wrote:
Hi,
In my cache.log i am seeing one error: "page faults with physical i/o:
1" other than that nothing on this box has changed.
Hi Dave,
It does not matter if there is only 1 page fault.
For my firewall i'm using pf, and i use an rdr pass rule to redirect
any internal lan traffic to the router's squid port, this has worked fine
so far.
Since it was working a few days ago, pf must be doing it's job right.
Would the core file be helpful?
Well the core file would be helpful for Squid developers. I am not
familiar with it:)
Here's my squid.conf file, thanks a lot.
Dave.
http_port 127.0.0.1:3128 transparent
You could use:
http_port 3128 transparent right? Have you tried using your proxy server
manually in your web browser and tried browsing?
icp_port 0
hierarchy_stoplist cgi-bin ?
cache_mem 48 MB
cache_swap_high 100%
cache_swap_low 80%
Why use 100% for cache_swap_high? You can use 95% right?
maximum_object_size 4096 KB
minimum_object_size 0 KB
maximum_object_size_in_memory 8 KB
ipcache_size 1024
ipcache_low 90
ipcache_high 95
fqdncache_size 1024
cache_replacement_policy lru
memory_replacement_policy lru
cache_dir diskd /usr/local/squid/cache 600 32 512
600 MB could be a bit small for a cache don't you think so? But it's
perfectly your choice.
access_log /usr/local/squid/logs/access.log squid
cache_log /usr/local/squid/logs/cache.log
cache_store_log none
emulate_httpd_log off
I prefer emulate_httpd_log on. But your choice might be different.
log_ip_on_direct on
mime_table /usr/local/etc/squid/mime.conf
log_mime_hdrs off
pid_filename /usr/local/squid/logs/squid.pid
log_fqdn off
check_hostnames off
allow_underscore off
unlinkd_program /usr/local/libexec/squid/unlinkd
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
acl our_networks src 192.168.5.0/24
acl chat dstdomain "/usr/local/etc/squid/chat.txt"
acl porn url_regex "/usr/local/etc/squid/porn"
acl spyware dstdomain "/usr/local/etc/squid/spyware.acl"
http_access allow our_networks !chat !spyware !porn
How many entries do you have in the above ACLs? If there are thousands of
them, it could be one of the reasons why your Squid is slow and giving
timeouts.
http_access deny all
http_reply_access allow all
cache_mgr user@xxxxxxxxxxx
cache_effective_user squid
httpd_suppress_version_string on
half_closed_clients off
redirect_program /usr/local/libexec/bannerfilter/redirector.pl
If all fails, why do you try deleting your cache_dir and recreate it.
Might work for your case!
Thanking you...
----- Original Message ----- From: "Tek Bahadur Limbu"
<teklimbu@xxxxxxxxxxxx>
To: "Dave" <dmehler26@xxxxxxxxxx>
Cc: <squid-users@xxxxxxxxxxxxxxx>
Sent: Monday, June 25, 2007 2:07 PM
Subject: Re: FreeBSD Squid timeout issue
Dave wrote:
Hello,
This is a strange one. I've got a FreeBSD 6.2 router with squid on
it for transparent proxy. It has been working fine, until about 3 days
ago when i noticed one of my internal machines wasn't completing an
http transaction, in this case downloading of it's ports index. The
connection would start out extremely slowly and eventually timeout then
giving an error about a truncated file. I checked my firewall, hard
disks, debug logs, messages everything, couldn't find any error msgs or
anything obviously wrong. This morning an internal machine, this one a
centos box, began failing with it's yum updates, giving timeout errors
on retrieving rpm files from http sites. Again, i ran the log checks,
didn't see anything. So, i next checked the firewall, nothing in
debug.log or messages, but in the /usr/local/squid/logs directory i
found two things. The first was that the failed transactions were all
returning http response code 206, timeout? The second was that i had a
43 mb core file. I shut down squid, turned off the transparent redirect
rule in my firewall and everything started working normally. If this
core file is useful in debugging i'd like to know what to do or where
to send it, i can post it on a web page if interested. I'd appreciate
any suggestions.
The squid version used is 2.6.13, memory and cpu usage during the
times in question are not even moving, this system is not in any way
heavily loaded.
Hi Dave,
Are you sure that you did not modify anything substantial in the past 3
days? Firewall rules, sysctl tunables in your FreeBSD box?
The core file suggests that your Squid might have crashed. Are you sure
that there is nothing in your cache.log?
Which firewall do you use to do transproxy? Can you show us your
relevant firewall rules?
Also posting your squid.conf might help. How many users are accessing
your cache normally? If you manually use your proxy server in your web
browser, does it help speed up the web requests?
Thanking you...
Any suggestions appreciated.
Thanks.
Dave.
