[squid-users] How I fixed it... Re: [squid-users] SO_FAIL

From: <[email protected]>
Date: Wed, 18 Aug 2004 17:54:38 +1000

Quoting lists@dedicated-web.net:

> Quoting Henrik Nordstrom <hno@squid-cache.org>:
>
> > On Wed, 7 Jul 2004, Sunil Mohan Ranta wrote:
> >
> > >
> > > i am getting SO_FAIL messages in store.log
> > > and no cache is being created on my system
> > > the size of of cache_dir is constant at 17MB
> >
> > Any error messages in cache.log?
> >
> > REgards
> > Henrik
> >
> >
>
> Strangely enough I have been having the same problem (no corresponding error in
> cache.log BTW), so I backed up my squid.conf, deleted all the entries in my cache
> dir and used the default squid.conf, modifying only the following:
>
> http_port 80
> http_port 3128
> http_port 8080
> cache_dir ufs /share/cache 100 16 256
> http_access allow all
> cache_effective_user squid
> cache_effective_group squid
>
> And the problem dissapeared! I haven't gone so far as to track down what part of
> my
> old config was causing the problem, but at least now I know it was something in
> the
> config (and not a problem with how squid was compiled or a directory permissions
> problem).
>
> I'll post an update when I have traced the cause.
>
> Regards,
> Rob Hadfield
>
>

Ok, I replicated the problem by:
* Changing:
       cache_replacement_policy heap LFUDA
* Stopped Squid
* Deleted the contents of my cache_dir
* Started Squid (cache dir rebuilt itself)
* store.log started logging the following for everything:
        ... SO_FAIL -1 FFFFFFFF ...
* Stopped Squid
* Deleted the contents of my cache_dir
* Changed:
        cache_replacement_policy lru
* Started Squid (cache dir rebuilt itself)
* store.log started logging the following swapouts:
        ... SWAPOUT 00 00000000 ...
        ... SWAPOUT 00 00000001 ...
        etc ...

Now this may be due to my misunderstanding of how "cache_replacement_policy heap
LFUDA" is supposed to work, but the comments in the config say this about it:

# The heap LFUDA policy keeps popular objects in cache regardless of
# their size and thus optimizes byte hit rate at the expense of
# hit rate since one large, popular object will prevent many
# smaller, slightly less popular objects from being cached.

So is it my misunderstanding, or is it a bug?

Regards,
Rob Hadfield
Received on Wed Aug 18 2004 - 01:54:42 MDT

This archive was generated by hypermail pre-2.1.9 : Wed Sep 01 2004 - 12:00:02 MDT