On Thursday 07 August 2003 20.30, Adam wrote:
> Brian wrote about "--enable-async-io"
>
> > i didn't realize that squid would set it be default. the
> > documentation is a little thing about that.
>
> An older post by Henrik says it will set it to 16 by default.
It uses 16 per cache_dir by default.
1 cache_dir -> 16 threads
2 cache_dir -> 32 threads
3 cache_dir -> 48 threads
etc
Now this will change slightly in 2.5.STABLE4 to not add as many
threads per new cache_dir as having that many threads is overkill. It
is still starting at 16 for a single cache_dir however, but will grow
less per additional cache_dir. See the "Known bugs/patches" page for
details.
> > parse runs no problems. --enable-storeio=aufs is automatically
> > set by --enable-async-io
>
> Just checked with "configure -help" and you are right - guess I
> forgot...
--enable-async-io is a old configure directive mostly kept for
compability with Squid-2.2 and earlier, and will probably go away
eventually, so it is a good idea to use the new directives today and
you will be prepared the day backwards support for --enable-async-io
is removed.
> This is news to me. What makes you say that? I have my cache on
> an Ultra 60 running 2.8 and mount the cache_dir's with the mount
> options "noatime,logging" but that is it. Still I've heard VxFS
> is a high performance filesystem so I assume it runs in the kernel,
> not another layer of indirection on top of the UFS base?
Older Solaris version had trouble with Squid, causign the filesystems
to become very fragmented. But it is very easy to tune Solaris UFS to
deal with Squid nicely. See the Squid FAQ section on Solaris.
One thing to note about Solaris UFS is that it is a synchronous
filesystem. You can gain a significant performance increase for Squid
cache operations if you use a transaction log on a separate drive
(using Disksuite, not the built in simpler log).
> I went overboard and then tuned it down to 64MB.
A cache_mem of 64MB is probably overkill for a proxy-cache.
For a Squid running in accelerator mode (not to be confused with
transparent proxying) it is probably way to little however.
> One other thought: originally I had compiled squid as a 64bit app.
> Not only was I told that it had no practical benefit for squid but
> I noticed that given the larger address size, more RAM was used and
> some other problems cropped up. So not sure if your server is in
> 64 or 32 bit mode, but I'd stick to 32bit since it won't help to go
> 64 and seemed to increase RAM usage (YMMV).
Defenitely recommended at the moment.
There is basically only two reasons why to go to 64 bits for Squid
a) Support for files larger than 2GB. Most notably support for very
large access.log. This can however be managed by making sure to
rotate the logs often to not hit the 2GB file size limit..
b) Support for very large amounts of memory to support very large
caches (more than 3GB process size or 300GB of cache disks). But if
you reach these sizes you should probably have more than one Squid
anyway..
As you noted Squid has not been very much tested in 64 bits and there
is likely some issues which does not show up in 32 bits. Some years
ago I ran Squid on Alpha and it ran quite well after the worst 64/32
bit bugs had been corrected, but I have not tried Squid in 64 bits
for a long time now.
Most 64/32 bit errors will just be cosmetic errors where odd values
pop up in various log files and compiler warnings when building
Squid, but there may also be more noticeable errors.
Squid is almost exclusively developed on Intel IA32 architecture with
Linux or FreeBSD as this is the platforms readily available to the
developers. If there is a need to have support improved for another
platform then several of the developers (myself included) are happy
to accept decent hardware donations or contracting to improve Squid.
Contact squid-dev@squid-cache.org or selected developers for details.
Regards
Henrik
-- Donations welcome if you consider my Free Squid support helpful. https://www.paypal.com/xclick/business=hno%40squid-cache.org If you need commercial Squid support or cost effective Squid or firewall appliances please refer to MARA Systems AB, Sweden http://www.marasystems.com/, info@marasystems.comReceived on Thu Aug 07 2003 - 14:04:03 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:18:46 MST