Re: [squid-users] assertion failed: store_dir_diskd.c:1645: "buf"

Oh, goodness...another innocent soul being bitten by the time-hack...

Get rid of some of the excess stuff. A mostly default configure is fine
for most people (that's why they are the default). Are you actually
using or needing htcp? icmp? carp? xmalloc-statistics? referer-log?
dlmalloc? useragent-log? gnuregex? Even know what most of those things
are? Of course not...leave them at their defaults! Defaults are your
friend.

Here's what I use for the packages we ship on our boxes, and you
wouldn't be insane to go with something similar (but leave out some of
the extra stuff that you don't plan to use--I have to support a wide
range of environments):

./configure \
--enable-poll --enable-snmp --enable-removal-policies="heap,lru" \
--enable-storeio="aufs,diskd,ufs" --enable-underscores \
--enable-delay-pools --enable-linux-netfilter \
--with-pthreads --enable-auth-modules="LDAP,NCSA,PAM,SMB,MSNT"

It is probably safe for you to leave out delay pools (gonna do any
bandwidth limiting?) as well as any or all of the auth_modules, unless
you will be authenticating users.

Notice there are no weird options that I'm not real sure of what they do
in there. Like, what exactly is HTCP or CARP? (OK, I know what they
are, but do you? I know I don't need 'em, and I bet dollars to donuts
you don't need them either. ;-)

Many of those options are there to address a specific problem on a
specific platform (like dlmalloc, and gnuregex). You're running
Linux--it already has a dlmalloc derived malloc library, and a gnu
regex library. The versions on your machine is probably measurably
better than what using those options will provide. xmalloc statistic is
a debugging aid. useragant-log and referer-log are probably only of
interest if you are running Squid as a website accelerator.
cache-digests are neat, but only useful for multiple caches in a cluster.

Anyway, odds are if you don't know what it does and it isn't on by
default you ought to leave it alone. Some of the options can actually
be very damaging to Squids stability or performance (enable-time-hack is
an example of both, a search for it in the list archives will give you a
long and sordid story of woe for all who tread there).

So, in summary: Turn off some of the silly configure options. Switch
your box to aufs instead of diskd (aufs performs better on Linux).
Switch your cache_dir partition to reiserfs. Relax and watch everything
work nicely (probably, a 1000 PCs on a LAN could potentially generate a
lot of traffic--maybe more than your box will handle--but if you're only
hitting a couple of redirectors at any given time you should be fine).

David Carson wrote:

> Hi,
>
> Thanks for the reply about aufs. My original question may seem like a dumb
> one, but I'm continuing to learn about Squid and its capabilities.
>
> I did recompile squid with the following configure options:
>
> ./configure --prefix=/opt/squid \
> --enable-cache-digests \
> --enable-icmp \
> --enable-htcp \
> --enable-wccp \
> --enable-carp \
> --enable-unlinkd \
> --enable-xmalloc-statistics \
> --enable-useragent-log \
> --enable-kill-parent-hack \
> --enable-gnuregex \
> --enable-referer-log \
> --enable-time-hack \
> --enable-storeio=diskd,aufs \
> --enable-cachemgr-hostname \
> --enable-dlmalloc \
> --with-pthreads
>
> The aufs type compiled with diskd and with threads. Corresponding line
> in squid.conf file is:
>
> cache_dir diskd /var/cache/www/data 5000 16 256 Q1=64 Q2=72
>
> I know the Q1 and Q2 parameters are the default values but I have them in
> as a reminder. If the above shouldn't have worked, then please tell me.
>
> We use squidGuard as a redirector with Squid. Every so often squid complains
> about "All redirector processes are busy". I've increased the number of
> redirector processes available, but it makes no difference.
>
> I then began to wonder if squid itself was the problem and there was some
> sort of blocking going on. As far as I know, squid only ever uses the top 2
> or 3 squidGuard redirector processes.
>
> That's why I've started tinkering with the compile options and the
> configuration options of squid. I'm trying to make it efficient as
> possible. (To see if that sorts squidGuard.)
>
> If anyone has any suggestions as to how I should compile and configure
> squid to run efficiently, especially with squidGuard, then please tell
> me. Environment is Intel based machine with 512Mb RAM, with 2 Pentium III
> 1 GHz processors. Surely the machine is OK to handle squid and squidGuard?
> Number of client machines is around 1000 PCs. I'm particularly interested
> in the cache_dir size. Squid has a 10Gb partition in which to play, using
> standard ext2 file system. (Maybe the problem lies here?)
>
> I don't mind receiving suggestions off list. I'd summarise responses and
> post them back.
>
> Again, any help appreciated.
>
> Regards,
>
> DC
>
>
>>Date: Thu, 28 Feb 2002 16:01:00 -0600
>>From: Joe Cooper <joe@swelltech.com>
>>To: David Carson <david.carson@abdn.ac.uk>
>>Cc: squid-users@squid-cache.org
>>MIME-version: 1.0
>>Content-transfer-encoding: 7BIT
>>X-Accept-Language: en-us
>>User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
>>Subject: Re: [squid-users] assertion failed: store_dir_diskd.c:1645: "buf"
>>X-Scanner: exiscan *16gYdI-0003Uj-00*UIga.L0OrFk*
>>
>>I don't have any suggestions about your problem...but I can answer this
>>part of your post...
>>
>>David Carson wrote:
>>
>>
>>
>>>Out of curiousity, has anyone built squid on Linux with 2.4.x kernel with
>>>diskd using aufs? If so, what command line parameter was supplied to
>>>the configure script?
>>>
>>Huh? diskd and aufs are separate storage types. You use one or the other.
>>
>>
>>For Linux I recommend using aufs, if high throughput is required. And
>>in that case just add "aufs" to the list of storeio types, and configure
>>your cache_dir line to use aufs instead of diskd.
>>
>>--
>>Joe Cooper <joe@swelltech.com>
>>http://www.swelltech.com
>>Web Caching Appliances and Support
>>
>>
>
>
>

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support