Re: [squid-users] FreeBSD Squid timeout issue

page faults with physical i/o: 1?

    Are you sure about your Hard Disk? I mean did you check there is no
Bad Sectors on The HD?

JC

Tek Bahadur Limbu escribió:
> 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@example.com
>> 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@wlink.com.np>
>> To: "Dave" <dmehler26@woh.rr.com>
>> Cc: <squid-users@squid-cache.org>
>> Sent: Monday, June 25, 2007 2:07 PM
>> Subject: Re: [squid-users] 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.
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
Received on Tue Jun 26 2007 - 05:54:32 MDT