Re: [squid-users] no_cache and Process Filedescriptors Allocation menu don't agree

Adam wrote:
>
> Hello,
>
> I am wondering both why the Process Filedescriptor Allocation table logs
> file types set to "no_cache" and whether Nread and Nwrite means Number FD's
> or Bytes read and written or something else. If it is Bytes, it does not
> seem to be accurate since the file is 5+MB.
>
> Short background (the why): Our Squid server is 3-4 times slower than
> surfing directly to the internet. From our reading and using the Cachmgr
> cgi, it seems
> that much of our bottleneck is I/O and much of that is streaming audio/video
> (users listening to internet radio). The server Ultra 60 Sun server running
> Solaris 8
> only has one internal SCSI controller that runs the two internal disks: they
> are mirrored using disksuite.
> Squid version is: Squid Cache: Version 2.5.STABLE1-20030307
> configure
> options: --enable-dlmalloc --enable-async-io --enable-storeio=aufs,diskd,uf
> s --enable-removal-policies=heap,lru --enable-delay-pools
> --disable-icmp --disable-ident --enable-cachemgr-hostname=ourproxy
>
> Using the Cachemgr.cgi script's "Process Filedescriptor Allocation" printout
> we can see many users doing streaming media (.asx, .wmv, etc.). We can't
> arbitrarily block these until a policy has been developed and rolled out to
> each and every user. So in the meantime I want to not cache the streaming
> media to reduce disk writes. Everyone is listening to different (radio)
> stations and since the content changes, our feeling is "why cache it?"
> Also we figure that this will alleviate some of the I/O contention for
> writing to internal the internal disk. If this reasoning is wrong-headed,
> please advise. We plan on rolling out delay pools soon but are trying one
> thing at a time.
>
> So my question is: is the server no longer caching, now that I have added
> these acl/no_cache directives to the squid.conf file:
> acl zipfiles urlpath_regex -i \.zip$ \.asf$ \.tar$ \.asx$ \.wmv$
> \.mpg$ \.rm$ \.mov$ \.iso$ \.mpeg$
> no_cache deny zipfiles
>
> From reading the FAQ and the mailing list via groups.google, I think the
> answer would be YES it's no longer caching. cache.log has nothing in it
> (good sign) except my own accesses to the cachemgr.cgi and access.log logs
> this line once the transfer is completed: 1048619816.535 595467 192.168.1.4
> TCP_MISS/206 3283803 GET http://205.225.141.21/BerkeleyDB.tar -
> DIRECT/205.225.141.21 application/x-tar
>
> However the Process Filedescriptor Allocation table still actively shows
> the file and the Nread and Nwrite columns continue growing as the file
> continues downloading. The numbers increment as the file is further
> downloaded though they don't match the bytes. Since the ratio is about 1.6:1
> (bytes in BerkeleyDB.tar to the Nread or Nwrite) I am wondering what the
> number could represent. It's not bytes and I can't believe there is 1.6 FD
> per byte (that wouldn't be efficient). So what are Nread and Nwrite
> supposed to represent?
>
> Lastly, since the idea of enabling no_cache is to not have any additional
> disk reads/writes I am wondering why this is still logging in the sub-menu?
> Can anyone tell me why and/or if I am doing something wrong or making
> incorrect assumptions?

  I think the 'fd mechanism' is always used in Squid to read data,
 for a particular object.
 Hence this is unrelated to a no_cache directive for certain extensions.

 M.

>
> thanks,
>
> Adam
>
> Here is the Cachemgr.cgi Process Filedescriptor Allocation just prior to the
> download finishing:
> Active file descriptors:
> File Type Tout Nread * Nwrite * Remote Address Description
> ---- ------ ---- -------- -------- --------------------- -------------------
> -----------
> 3 Log 0 0 0
> /logs/cache.log
> 6 Socket 0 1291 412 .0 DNS Socket
> 7 File 0 0 347721
> /logs/access.log
> 8 Pipe 0 0 0 unlinkd ->
> squid
> 9 Socket 0 0* 0 .0 HTTP Socket
> 10 Socket 0 0* 0 .0 HTTP Socket
> 11 Pipe 0 0 0 squid ->
> unlinkd
> 12 Socket 0 0* 0 .0 HTTP Socket
> 13 Socket 0 0* 0 .0 HTTP Socket
> 14 File 0 0 192
> /cache/swap.state
> 15 File 0 0 192
> /cache2/swap.state
> 16 Socket 1430 572* 3254047 192.168.1.4.2028
> http://extern.site.com/BerkeleyDB.tar
> 17 Socket 4 3254043* 1310 extern.site.com.80
> http://extern.site.com/BerkeleyDB.tar
> 18 Socket 1440 162* 0 192.168.1.4.53586
> cache_object://squid.mydom.com/filedescriptors
> 24 Pipe 0 0* 0 async-io
> completetion event: main
> 25 Pipe 0 0 0 async-io
> completetion event: threads

-- 
 'Time is a consequence of Matter thus
 General Relativity is a direct consequence of QM
 (M.E. Mar 2002)