Re: [squid-users] Resource temporarily unavailable tests tests=FROM_NAME_NO_SPACES,DOUBLE_CAPSWORD version=2.31

From: Brian Hechinger <[email protected]>
Date: Thu, 7 Aug 2003 13:23:22 -0400

On Thu, Aug 07, 2003 at 10:06:37AM -0700, Adam wrote:
>
> Well I assume you know the chorus of: upgrade to a newer version - yours is

the SmartFilter patch doesn't apply cleanly to STABLE3, so i just went with
STABLE1. i plan on manually patching the latest STABLE, but that was a
thing to be done after i got it all up and running. this could be the
ideal time for that. ;)

> Also: why did you set async-io to 32? I just used "--enable-async-io" and
> let squid set it's default. Maybe your way is better but just so you know

i didn't realize that squid would set it be default. the documentation is
a little thing about that.

> why you did that and that it's not at all related to your aufs problem....
> Also I thought you had to include aufs as one of the compile options? I did
> (--enable-storeio=aufs,ufs). Maybe I didn't have to since I assume your
> squid would squawk if it weren't compiled in (does "squid -k parse" run

parse runs no problems. --enable-storeio=aufs is automatically set by
--enable-async-io

> cleanly?). Unrelated but I'd add --enable-removal-policies=heap,lru so you
> can later try the heap algorithms (we use GDSF). Lastly, why are you

i will add that when i rebuild the latest, thanks for the tip.

> enabling ssl? If you think you need to enable ssl to pass https/443 traffic
> that is incorrect. From reading Henrik and other's posts, it looks like
> lots of people compile it in when that wasn't what they really wanted (see
> the archives for better explanations). If you don't need it, I'd suggest
> leaving it out.

hmm, then i will leave it out, since all i need to do is pass SSL.

> I'm pretty sure Henrik confirmed for me that the cache_dir sizing parameter
> is in MB's. It looks like earlier you posted the output from a "df -k" and
> if so, you've got 2GB partitions. Above you've defined cache_dirs of
> 1781GB (gigabytes). I just checked my conf default and in fact the value is
> MB's. So drop that down to: cache_dir aufs /squid/s00 1781 16 256

that could explain some other behavior, heh. i will fix that post-haste.

> For such small cache_dir's, your RAM vis-a-vis sizing is fine but as you
> make a larger cache, be sure to use the FAQ to calculate the memory
> correctly so you don't make your cache_dir's larger than RAM+squid's other
> RAM needs will require.

the 2G of ram in the machine will be dedicated to squid once it is deemed
ready to replace netscape proxy. how much disk do i need to back that up,
and how much ram should i leave for the OS?

> Since you original problem "resource temporarily unavailable" sounds like a
> resource contention issue, I would try to get squid it's OWN disk, not just
> partition. aufs is great (I use it as well) but my uninformed opinion would
> be to give it all the I/O you can - check the archives I am pretty sure they
> would confirm that. The fact that you don't see this error often in the

as of right now this is impossible, and not really needed. this error seems
to be harmless, people can still use the cache just fine. once we turn off
netscape and put this in its place, i can dedicate all three 9G disks to
squid. i will also put VxFS on those disks since UFS on solaris is a known
issue with AUFS.

> archives would imply that it is probably your configuration. The fact that
> you've done two things squid recommends you not do (have a huge/incorrecly
> defined cach_dir allotment and put them on non-dedicated disks) my guess
> would be that the error stems from one or both of those and once you've
> fixed both you should be ok.

well, let's home that the former is the case and that it has just been fixed!!

thanks for the help!

-brian

-- 
"You know, evil comes in many forms, be it a man-eating cow or Joseph Stalin.
But you can't let the package hide the pudding. Evil is just plain bad! You
don't cotton to it! You gotta smack it on the nose with the rolled up newspaper
of goodness! Bad dog! Bad dog!"		-- The Tick
Received on Thu Aug 07 2003 - 11:24:49 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:18:46 MST