[SQU] Squid box crashed & Store DirStat

Hello,

Yesterday I have downloaded/installed Squid-2.4.20010212000.tar.gz on
FreeBSD-4.2STABLE w/IP Filter 3.4.16 (Dual Pentium III 500MHz, 1GB
RAM, 2x18GB SCSI-3 HDD, 10/100M) machine. It is working as transparent
proxy/cache.

Today our Squid box crashed, time between crashes different.
I have compile Squid with following:
./configure --prefix=/usr/local/squid --disable-wccp --enable-useradgent
--enable-underscores --disable-ident-lookups --enable-snmp --enable-ipf-transparent
--disable-http-violations --enable-poll --enable-forw-via-db
--enable-storeio=diskd --enable-removal-policies=heap
--enable-cachemgr=cache.xxx.xxx.xxx

On system console some appears error regarding page faults.
Unfortunately I can't capture those error messages.

My config looks like:
http_port 8080
cache_mem 384 MB
cache_swap_low 90
cache_swap_high 95
cache_replacement_policy heap LFUDA
memory_replacement_policy heap LFUDA
cache_dir diskd -1 /cache0 10080 24 256 64 72
cache_dir diskd -1 /cache1 10080 24 256 64 72
cache_access_log /usr/local/squid/logs/access.log
cache_log /usr/local/squid/logs/cache.log
cache_store_log none
mime_table /usr/local/squid/etc/mime.conf
debug_options ALL,1
ftp_list_width 64
ftp_passive on
quick_abort_min 0 KB
quick_abort_max 0 KB
quick_abort_pct 100
half_closed_clients off

<There is acl list and http_access, miss_access allow list>

httpd_accel_host virtual
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
logfile_rotate 1
memory_pools off

All other parameters by default.

My natrules:
rdr fxp0 0.0.0.0/0 port 80 -> xxx.xxx.xxx.xxx port 8080 tcp

My ipfrules:
pass in quick on lo0 all
pass out quick on lo0 all
pass in quick on fxp0 all
pass out quick on fxp0 all
pass in quick proto tcp from any to xxx.xxx.xxx.xxx/32 port = 80

How can I to solve it? Is this configuration correct/optimal?

Please, any suggestion?

I can to see following through cachemgr.cgi:

Store Directory Statistics:
Store Entries : 53773
Maximum Swap Size : 20643840 KB
Current Store Swap Size: 346721 KB
Current Capacity : 2% used, 98% free

Store Directory #0 (diskd): /cache0
FS Block Size 1024 Bytes
First level subdirectories: 24
Second level subdirectories: 256
Maximum Size: 10321920 KB
Current Size: 173347 KB
Percent Used: 1.68%
Filemap bits in use: 26531 of 32768 (81%)
Filesystem Space in use: 184035/11909978 KB (2%)
Filesystem Inodes in use: 32702/2975998 (1%)
Flags: SELECTED
Pending operations: 0

Store Directory #1 (diskd): /cache1
FS Block Size 1024 Bytes
First level subdirectories: 24
Second level subdirectories: 256
Maximum Size: 10321920 KB
Current Size: 173374 KB
Percent Used: 1.68%
Filemap bits in use: 26210 of 32768 (80%)
Filesystem Space in use: 182831/11909978 KB (2%)
Filesystem Inodes in use: 32381/2975998 (1%)
Flags:
Pending operations: 0

I don't understand why store directory usage is very low.
How can I to increase utilization of store directory?

Thank you,
Balgaa

On Wed, 7 Feb 2001, Marc G. Fournier wrote:

>
> FreeBSD 4.2 box, 3x18gig drives for cache, running "close to" latest
> version from CVS and 1gig of RAM on a Dual-Xeon 700, using softupdates ...
> damn, lookign at these numbers, the version in CVS has gone downhill?
> *raised eyebrow* All median of ~273ms?
>
> 60min:
>
> client_http.all_median_svc_time = 0.273318 seconds
> client_http.miss_median_svc_time = 0.764075 seconds
> client_http.nm_median_svc_time = 0.013086 seconds
> client_http.nh_median_svc_time = 0.469653 seconds
> client_http.hit_median_svc_time = 0.023168 seconds
>
> 5min:
>
> client_http.all_median_svc_time = 0.245243 seconds
> client_http.miss_median_svc_time = 0.723868 seconds
> client_http.nm_median_svc_time = 0.013086 seconds
> client_http.nh_median_svc_time = 0.399283 seconds
> client_http.hit_median_svc_time = 0.024508 seconds
>
>
>
> On Tue, 6 Feb 2001, Jon Mansey wrote:
>
> >
> > So you're getting around 32ms HIT times. Heres one of my 2.3 boxes, I
> > see around 23ms here using UFS.
> >
> > Median Service Times (seconds) 5 min 60 min:
> > HTTP Requests (All): 0.05951 0.09219
> > Cache Misses: 0.20843 0.20843
> > Cache Hits: 0.02317 0.02317
> > Near Hits: 0.12783 0.16775
> > Not-Modified Replies: 0.01235 0.01648
> > DNS Lookups: 0.01331 0.01046
> > ICP Queries: 0.00000 0.00000
> >
> > Maybe the the median access time is a little longer but it supports
> > higher load?
> >
> > jm
> >
> >
> > >This is from one of my Diskd boxes. Its P3 running FreeBSD 4.0 with 768
> > >MB of RAM and 6 x 4096 8 256 cache dirs. Your boxes are running FreeBSD
> > >right?
> > >
> > >
> > >Awais
> > >
> > >Median Service Times (seconds) 5 min 60 min:
> > > HTTP Requests (All): 0.80651 1.00114
> > > Cache Misses: 1.46131 1.54242
> > > Cache Hits: 0.03241 0.03241
> > > Near Hits: 1.54242 1.54242
> > > Not-Modified Replies: 0.01035 0.01309
> > > DNS Lookups: 0.02336 0.03696
> > > ICP Queries: 0.00000 0.00000
> > >
> > >Jon Mansey wrote:
> > >
> > >> Median Service Times (seconds) 5 min 60 min:
> > >> HTTP Requests (All): 0.18699 0.18699
> > >> Cache Misses: 0.19742 0.20843
> > >> Cache Hits: 0.05951 0.05046
> > >> Near Hits: 0.15888 0.16775
> > >> Not-Modified Replies: 0.04519 0.04047
> > >> DNS Lookups: 0.02231 0.02336
> > >> ICP Queries: 0.00000 0.00000
> > >>
> > >> I thought diskd was supposed to improve disk access times?
> > >>
> > >> I think 50-60ms for cache hits is quite a bit slower than the 2.3
> > >> boxes I have running, they average 20ms.
> > >>
> > >> What times are others seeing?
> > >>
> > >> jm
> > >>
> > >> --
> > >> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
> > >
> > >--
> > >To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
> >
> > --
> >
> > jon@interpacket.net Chief Science Officer
> > ------------------------------------------------------------------
> > "The Global Leader in Internet Via Satellite"
> > InterPacket Networks, http://www.interpacket.net
> > (A Verestar Company) http://www.verestar.com
> > 1901 Main St. tel (310) 382 3300
> > Santa Monica, California 90405 fax (310) 382 3310
> > ------------------------------------------------------------------
> >
> > --
> > To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
> >
> >
>
> Marc G. Fournier marc.fournier@acadiau.ca
> Senior Systems Administrator Acadia University
>
> "These are my opinions, which are not necessarily shared by my employer"
>
> --
> To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
>
>

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html