ScriptAlias /Squid/cgi-bin/ /usr/local/squid/cgi-bin/
<Location /Squid/cgi-bin/cachemgr.cgi> order allow,deny allow from workstation.example.com </Location>
<Location /Squid/cgi-bin/cachemgr.cgi> AuthUserFile /path/to/password/file AuthGroupFile /dev/null AuthName User/Password Required AuthType Basic require user cachemanager </Location>
by Francesco ``kinkie'' Chemolli
Notice: this is not how things would get best done with Roxen, but this what you need to do go adhere to the example. Also, knowledge of basic Roxen configuration is required.
This is what's required to start up a fresh Virtual Server, only serving the cache manager. If you already have some Virtual Server you wish to use to host the Cache Manager, just add a new CGI support module to it.
Create a new virtual server, and set it to host http://www.example.com/. Add to it at least the following modules:
In the CGI scripting support module, section Settings, change the following settings:
In section Security, set Patterns to:
where 126.96.36.199 is the IP address for workstation.example.com
Save the configuration, and you're done.
acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl all src 0.0.0.0/0.0.0.0
http_access deny manager !localhost http_access allow all
$ telnet mycache.example.com 8080 GET cache_object://mycache.example.com/info HTTP/1.0
miss_access allow manager
% ./configure --enable-cachemgr-hostname=`hostname` ...
% cd src % rm cachemgr.o cachemgr.cgi % make cachemgr.cgi
logfile in your cache directory:
Pool for Request structures
Pool for in-memory object
If squid is much smaller than this field, run for cover! Something is very wrong, and you should probably restart squid.
TTL項目は"Time To Live" (i.e.,キャッシュエントリが正当な時間）を表します。 (期限切れなドキュメントは無効になります)
IP Cache Contents:
Hostname Flags lstref TTL N [IP-Number] gorn.cc.fh-lippe.de C 0 21581 1 188.8.131.52 lagrange.uni-paderborn.de C 6 21594 1 184.108.40.206 www.altavista.digital.com C 10 21299 4 220.127.116.11 ... 2/ftp.symantec.com DL 1583 -772855 0 Flags: C --> Cached D --> Dispatched N --> Negative Cached L --> Locked lstref: Time since last use TTL: Time-To-Live until information expires N: Count of addresses
FQDN Cache Contents:
IP-Number Flags TTL N Hostname 18.104.22.168 C -45570 1 andele.cs.tu-berlin.de 22.214.171.124 C -58133 1 komet.teuto.de 126.96.36.199 N -73747 0 Flags: C --> Cached D --> Dispatched N --> Negative Cached L --> Locked TTL: Time-To-Live until information expires N: Count of names
Jonathan Larmour によると、
これはsquidが実際のところスワッピングによって大量のメモリがスワップされる訳ではありません。 殆どのオペレーティングシステムでは、現実に使用される内の必要な一部（ロット）だけをディスクからメモリに読みとります。このため、Squidが実際に割り当てられるよりも多くのメモリを必要とした場合にページフォルト（page fault）となります。
スワッピングの回数やサイズが大きくなっているかを知るには、UNIXプラット ホームの場合には"vmstat"というプログラムを使う事ができます。例えばこれを "vmstat 5"とすれば、5秒ごとに結果が表示されます。 これを使いシステム全体でのスワッピングされていロットを知る事ができます。（より詳しい事は vmstatのmanページを見てください）
by Peter Wemm
There's two different operations at work, Paging and swapping. Paging is when individual pages are shuffled (either discarded or swapped to/from disk), while ``swapping'' generally means the entire process got sent to/from disk.
Needless to say, swapping a process is a pretty drastic event, and usually only reserved for when there's a memory crunch and paging out cannot free enough memory quickly enough. Also, there's some variation on how swapping is implemented in OS's. Some don't do it at all or do a hybrid of paging and swapping instead.
As you say, paging out doesn't necessarily involve disk IO, eg: text (code) pages are read-only and can simply be discarded if they are not used (and reloaded if/when needed). Data pages are also discarded if unmodified, and paged out if there's been any changes. Allocated memory (malloc) is always saved to disk since there's no executable file to recover the data from. mmap() memory is variable.. If it's backed from a file, it uses the same rules as the data segment of a file - ie: either discarded if unmodified or paged out.
There's also ``demand zeroing'' of pages as well that cause faults.. If you malloc memory and it calls brk()/sbrk() to allocate new pages, the chances are that you are allocated demand zero pages. Ie: the pages are not ``really'' attached to your process yet, but when you access them for the first time, the page fault causes the page to be connected to the process address space and zeroed - this saves unnecessary zeroing of pages that are allocated but never used.
The ``page faults with physical IO'' comes from the OS via getrusage(). It's highly OS dependent on what it means. Generally, it means that the process accessed a page that was not present in memory (for whatever reason) and there was disk access to fetch it. Many OS's load executables by demand paging as well, so the act of starting squid implicitly causes page faults with disk IO - however, many (but not all) OS's use ``read ahead'' and ``prefault'' heuristics to streamline the loading. Some OS's maintain ``intent queues'' so that pages can be selected as pageout candidates ahead of time. When (say) squid touches a freshly allocated demand zero page and one is needed, the OS can page out one of the candidates on the spot, causing a 'fault with physical IO' with demand zeroing of allocated memory which doesn't happen on many other OS's. (The other OS's generally put the process to sleep while the pageout daemon finds a page for it).
The meaning of ``swapping'' varies. On FreeBSD for example, swapping out is implemented as unlocking upages, kernel stack, PTD etc for aggressive pageout with the process. The only thing left of the process in memory is the 'struct proc'. The FreeBSD paging system is highly adaptive and can resort to paging in a way that is equivalent to the traditional swapping style operation (ie: entire process). FreeBSD also tries stealing pages from active processes in order to make space for disk cache. I suspect this is why setting 'memory_pools off' on the non-NOVM squids on FreeBSD is reported to work better - the VM/buffer system could be competing with squid to cache the same pages. It's a pity that squid cannot use mmap() to do file IO on the 4K chunks in it's memory pool (I can see that this is not a simple thing to do though, but that won't stop me wishing. :-).
by John Line
The comments so far have been about what paging/swapping figures mean in a ``traditional'' context, but it's worth bearing in mind that on some systems (Sun's Solaris 2, at least), the virtual memory and filesystem handling are unified and what a user process sees as reading or writing a file, the system simply sees as paging something in from disk or a page being updated so it needs to be paged out. (I suppose you could view it as similar to the operating system memory-mapping the files behind-the-scenes.)
The effect of this is that on Solaris 2, paging figures will also include file I/O. Or rather, the figures from vmstat certainly appear to include file I/O, and I presume (but can't quickly test) that figures such as those quoted by Squid will also include file I/O.
To confirm the above (which represents an impression from what I've read and observed, rather than 100% certain facts...), using an otherwise idle Sun Ultra 1 system system I just tried using cat (small, shouldn't need to page) to copy (a) one file to another, (b) a file to /dev/null, (c) /dev/zero to a file, and (d) /dev/zero to /dev/null (interrupting the last two with control-C after a while!), while watching with vmstat. 300-600 page-ins or page-outs per second when reading or writing a file (rather than a device), essentially zero in other cases (and when not cat-ing).
So ... beware assuming that all systems are similar and that paging figures represent *only* program code and data being shuffled to/from disk - they may also include the work in reading/writing all those files you were accessing...
You'll probably want to compare the number of page faults to the number of HTTP requests. If this ratio is close to, or exceeding 1, then Squid is paging too much.