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)
