• Choose a category
• All
• Classic-Fiction

The fifth line shows a few counters: locks, clients, and references. An entry with locks can't be removed. The clients counter shows how many clients are currently receiving data for this object. The refs counter shows how many times the object has been requested.

The sixth line shows the object's index to the on-disk storage. Each object has a 7-bit swap directory index and a 25-bit file number. Each storage scheme has a function to map these numbers into pathnames.

vm_objects: In-Memory and In-Transit Objects

This page is similar to All Cache Objects, except that it displays only objects that have a MemObject data structure. In other words, objects that are currently being requested or are stored in the memory cache. These objects are displayed like this:

KEY 5107D49BA7F9C6BA9559E006D6DDC4B2

GET http://www.rpgplanet.com/ac2hq/cartography/dynamic/LinvakMassif.jpg

STORE_PENDING NOT_IN_MEMORY SWAPOUT_WRITING PING_DONE

CACHABLE,DISPATCHED,VALIDATED

LV:1043286120 LU:1043286122 LM:1036015230 EX:-1

4 locks, 1 clients, 1 refs

Swap Dir 1, File 00X31BD9

inmem_lo: 184784

inmem_hi: 229840

swapout: 229376 bytes queued

swapout: 229509 bytes written

Client #0, 1533a1018

copy_offset: 217552

seen_offset: 217552

copy_size: 4096

flags:

As you can see, many of the lines are the same. However, the in-memory objects have a few additional lines. Directly following the cache key (MD5 checksum), Squid prints the request method and URI.

The inmem_lo and inmem_hi lines are byte offsets of the HTTP reply. They indicate the section of object data currently in memory. In most cases, the difference between these two should be less than the value of the maximum_object_size_in_memory directive.

The swapout: bytes queued line shows the offset for how many bytes have been given to the storage layer for writing. For objects in the SWAPOUT_DONE state, this value is the same as the object size. If the state is SWAPOUT_WRITING, Squid also shows the bytes written line, which indicates how many bytes have been successfully stored on disk.

If one or more clients are currently receiving the response, you'll see a section for each of them (Client #0 in this example). For each client, Squid reports another pair of offset values. The first, copy_offset, is the starting point for the last time the client-side asked for data from the storage system. The second, seen_offset, is the point at which the response data has been sent to the client. Note that copy_offset is always greater than or equal to seen_offset. The copy_size indicates the maximum amount of data the client can receive from the storage system.

openfd_objects: Objects with Swapout Files Open

The format of this page is the same as for In-Memory and In-Transit Objects. The objects reported on this page should all be in the SWAPOUT_WRITING state. The page is primarily useful to developers when trying to track down file-descriptor leaks.

io: Server-Side Network read( ) Size Histograms

This page displays a histogram for each of the following four server-side protocols: HTTP, FTP, Gopher, and WAIS. The histograms show how many bytes each read( ) call received. The information is primarily useful to developers for tuning buffer sizes and other aspects of the source code.

The bins of the histogram are logarithmic to accommodate the large scale of read sizes. Here is an example:

HTTP I/O

number of reads: 9016088

Read Histogram:

1- 1: 3082 0%

2- 2: 583 0%

3- 4: 905 0%

5- 8: 2666 0%

9- 16: 16690 0%

17- 32: 88046 1%

33- 64: 19712 0%

65- 128: 116655 1%

129- 256: 749259 8%

257- 512: 633075 7%

513- 1024: 903145 10%

1025- 2048: 3664862 41%

2049- 4096: 1643747 18%

4097- 8192: 789796 9%

8193-16384: 99476 1%

16385-32768: 30059 0%

In this case, you can see that the bin for 1025-2048 bytes is the most popular. When reading from an HTTP server, Squid got between 1025 and 2048 bytes per read 41% of the time.

counters: Traffic and Resource Counters

Squid maintains a data structure