Hello;
My responses below. Thank you all for the assistance, very much
appreciated. Is anyone interested in my posting the final squid.conf when
this is all said and done?
On 07.11 20:07, Vadim Pushkin wrote:
> I have a Sparc/Solaris 2.8 server which has the following:
>
> Squid-2.5.STABLE11
> Solaris 2.8 (w/4 CPU's)
> 4X Network ports (one listens on a switch for requests as well as
> connections to the Internet, the other I wish to configure on a private
> VLAN for ICP.)
>
> 64GB of space available for Squid use. (+ 1GB Swap)
> 1GB of memory available for Squid use.
>
> I am not sure if I am using both my hardware resources and my squid.conf
> properly, especially with regards to: cache_dir ufs /usr/squidcache 8192
16
> 256
Pardon, are you asking us if our squid is properly set up? It seems so, but
although I think there is no problem with it, you should NOT use "all" acl
to specify your clients. use "mynetwork" or so and define acl back as
"src 0.0.0.0/0"
Yes, I've changed this using Tim Rainier's excellent example. Thank you.
Are you asking us if you can tune it a bit more?
Yes, you can. You can use much more space - for 64 GB of disk space try:
cache_dir aufs /usr/squidcache 50000 64 256
you can increase maximum object size:
maximum_object_size 32 MB
and use heap LFUDA replacement policy:
cache_replacement_policy heap LFUDA
Thank you, your suggestions seem to make much more sense than what I had.
I hope you configured squid with heap removal policies and async IO allowed
I've configured squid like this:
./configure --prefix=/usr/local/squid --enable-storeio=diskd,ufs --enable-i
cmp --enable-snmp --enable-err-languages=English
--enable-default-err-language=E
nglish --disable-hostname-checks --enable-underscores --enable-stacktrace
What am I missing, if anything?
These?
--enable-heap-replacement
--enable-async-io[=N_THREADS] (Leave N blank?)
> /etc/system:
> ------------------
> set msgsys:msginfo_msgmax=2048
> set msgsys:msginfo_msgmnb=8192
> set msgsys:msginfo_msgmni=40
> set msgsys:msginfo_msgssz=64
> set msgsys:msginfo_msgtql=2048
>
> set shmsys:shminfo_shmmax=2097152
> set shmsys:shminfo_shmmni=32
> set shmsys:shminfo_shmseg=16
You don't need to tune these unless you use diskd. But on solaris, aufs
should be even faster.
I was just following the suggest in the FAQ.
I will test with your suggests using aufs. Thank you very much, though I
did not even think of using aufs as an option. Shall I compile like this?
--with-aufs-threads=N_THREADS (Leave N blank?, or do not use?)
--enable-storeio=ufs,aufs
At the moment I am having a discussion on why we should not be using Veritas
Disk Suite, I couldn't care less if we lose this data, and the mirror
overhead will slow things down alot, no?
.vp
