Библиотека сайта rus-linux.net
6. Squid Log Files
The logs are a valuable source of information about Squid workloads and performance. The logs record not only access information, but also system configuration errors and resource consumption (eg, memory, disk space). There are several log file maintained by Squid. Some have to be explicitely activated during compile time, others can safely be deactivated during run-time.
Есть несколько основополагающих компонет для всех лог-файлов. The time stamps logged into the log files are usually UTC seconds unless stated otherwise. The initial time stamp usually contains a millisecond extension.
The frequent time lookups on busy caches may have a performance impact on some systems. The compile time configuration option --enable-time-hack makes Squid only look up a new time in one second intervals. The implementation uses Unix's alarm() functionality. Note that the resolution of logged times is much coarser afterwards, and may not suffice for some log file analysis programs. Usually there is no need to fiddle with the timestamp hack.
6.1 squid.out
Если вы запускаетет ваш Squid из скрипта RunCache, то файл squid.out содержит время старта Squid, а также все сообщения о фатальных ошибках, генерируемых неудачным вызовом assert(). Если вы не используете RunCache, вы не увидите подобного файла.
6.2 cache.log
Файл cache.log содержит отладочную информацию и сообщения о ошибках, которые генерирует Squid. Если для запуска Squid вы используете скрипт RunCache или запускаете его с ключем -s, то копия некоторых сообщений попадет в ваш syslog. Использлвание отдельного файла для хранения лога Squid - вопрос личных предпочтений.
Для автоматических анализаторов логов файлу cache.log особо предложить нечего. Вы обычно будете обращаться к этому файлу для отчета о ошибках при программировании Squid, тестировании новых возможностей или поиске причин непонятного поведения прокси и т.п..
6.3 useragent.log
Этот лог-файл будет вестить, если:
- вы указали при сборке опцию --enable-useragent-log и
- вы указали в какой файл это попадет при помощи опции useragent_log.
В лог-файле user agent вы можете найти информацию о броузерах ваших клиентов. Использование этой опции вкупе с загруженным сквидом - не самая лучшая из идей.
6.4 store.log
The store.log file covers the objects currently kept on disk or removed ones. As a kind of transaction log it is ususally used for debugging purposes. A definitive statement, whether an object resides on your disks is only possible after analysing the complete log file. The release (deletion) of an object may be logged at a later time than the swap out (save to disk).
The store.log file may be of interest to log file analysis which looks into the objects on your disks and the time they spend there, or how many times a hot object was accessed. The latter may be covered by another log file, too. With knowledge of the cache_dir configuration option, this log file allows for a URL to filename mapping without recursing your cache disks. However, the Squid developers recommend to treat store.log primarily as a debug file, and so should you, unless you know what you are doing.
Формат строки, которая заносится в store.log состоит из одиннадцати полей разделенных пробелами leven space-separated columns, compare with the storeLog() function in file src/store_log.c:
"%9d.%03d %-7s %08X %4d %9d %9d %9d %s %d/%d %s %s\n"
- time
время, когда запись попала в лог, в UTC с миллисекундами.
- action
The action the object was sumitted to, compare with src/store_log.c:
- CREATE не используется.
- RELEASE объект был удален из кеша (см. также номер файла).
- SWAPOUT объект был сохранен на диск.
- SWAPIN объект есть на диске и прочитан в память.
- file number
The file number for the object storage file. Please note that the path to this file is calculated according to your cache_dir configuration.
A file number of FFFFFFFF denominates "memory only" objects. Any action code for such a file number refers to an object which existed only in memory, not on disk. For instance, if a RELEASE code was logged with file number FFFFFFFF, the object existed only in memory, and was released from memory.
- status
код статуса HTTP-ответа.
- datehdr
заначение заголовка HTTP "Date: " ответа.
- lastmod
значение заголовка HTTP "Last-Modified: " ответа.
- expires
значение заголовка HTTP "Expires: " ответа.
- type
The HTTP "Content-Type" major value, or "unknown" if it cannot be determined.
- sizes
This column consists of two slash separated fields:
- The advertised content length from the HTTP "Content-Length: " reply header.
- The size actually read.
If the advertised (or expected) length is missing, it will be set to zero. If the advertised length is not zero, but not equal to the real length, the object will be realeased from the cache.
- method
The request method for the object, e.g. GET.
- key
The key to the object, usually the URL.
The timestamp format for the columns Date to Expires are all expressed in UTC seconds. The actual values are parsed from the HTTP reply headers. An unparsable header is represented by a value of -1, and a missing header is represented by a value of -2.
The column key usually contains just the URL of the object. Some objects though will never become public. Thus the key is said to include a unique integer number and the request method in addition to the URL.
6.5 hierarchy.log
Этот лог-файл используется только в версии Squid-1.0. Его формат
[date] URL peerstatus peerhost
6.6 access.log
Most log file analysis program are based on the entries in access.log. Currently, there are two file formats possible for the log file, depending on your configuration for the emulate_httpd_log option. By default, Squid will log in its native log file format. If the above option is enabled, Squid will log in the common log file format as defined by the CERN web daemon.
The common log file format contains other information than the native log file, and less. The native format contains more information for the admin interested in cache evaluation.
The common log file format
The Common Logfile Format is used by numerous HTTP servers. This format consists of the following seven fields:
remotehost rfc931 authuser [date] "method URL" status bytes
It is parsable by a variety of tools. The common format contains different information than the native log file format. The HTTP version is logged, which is not logged in native log file format.
The native log file format
The native format is different for different major versions of Squid. For Squid-1.0 it is:
time elapsed remotehost code/status/peerstatus bytes method URL
For Squid-1.1, the information from the hierarchy.log was moved into access.log. The format is:
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type
For Squid-2 the columns stay the same, though the content within may change a little.
The native log file format logs more and different information than the common log file format: the request duration, some timeout information, the next upstream server address, and the content type.
There exist tools, which convert one file format into the other. Please mind that even though the log formats share most information, both formats contain information which is not part of the other format, and thus this part of the information is lost when converting. Especially converting back and forth is not possible without loss.
squid2common.pl is a conversion utility, which converts any of the squid log file formats into the old CERN proxy style output. There exist tools to analyse, evaluate and graph results from that format.
access.log native format in detail
It is recommended though to use Squid's native log format due to its greater amount of information made available for later analysis. The print format line for native access.log entries looks like this:
"%9d.%03d %6d %s %s/%03d %d %s %s %s %s%s/%s %s"
Therefore, an access.log entry usually consists of (at least) 10 columns separated by one ore more spaces:
- time
A Unix timestamp as UTC seconds with a millisecond resolution. You can convert Unix timestamps into something more human readable using this short perl script:
#! /usr/bin/perl -p s/^\d+\.\d+/localtime $&/e;
- duration
The elapsed time considers how many milliseconds the transaction busied the cache. It differs in interpretation between TCP and UDP:
- For HTTP/1.0, this is basically the time between accept() and close().
- For persistent connections, this ought to be the time between scheduling the reply and finishing sending it.
- For ICP, this is the time between scheduling a reply and actually sending it.
Please note that the entries are logged after the reply finished being sent, not during the lifetime of the transaction.
- client address
The IP address of the requesting instance, the client IP address. The client_netmask configuration option can distort the clients for data protection reasons, but it makes analysis more difficult. Often it is better to use one of the log file anonymizers.
Also, the log_fqdn configuration option may log the fully qualified domain name of the client instead of the dotted quad. The use of that option is discouraged due to its performance impact.
- result codes
This column is made up of two entries separated by a slash. This column encodes the transaction result:
- The cache result of the request contains information on the kind of
request, how it was satisfied, or in what way it failed. Please refer
to section
Squid result codes
for valid symbolic result codes.
Several codes from older versions are no longer available, were renamed, or split. Especially the ERR_ codes do not seem to appear in the log file any more. Also refer to section Squid result codes for details on the codes no longer available in Squid-2.
The NOVM versions and Squid-2 also rely on the Unix buffer cache, thus you will see less TCP_MEM_HITs than with a Squid-1. Basically, the NOVM feature relies on read() to obtain an object, but due to the kernel buffer cache, no disk activity is needed. Only small objects (below 8KByte) are kept in Squid's part of main memory.
- The status part contains the HTTP result codes with some Squid specific extensions. Squid uses a subset of the RFC defined error codes for HTTP. Refer to section status codes for details of the status codes recognized by a Squid-2.
- The cache result of the request contains information on the kind of
request, how it was satisfied, or in what way it failed. Please refer
to section
Squid result codes
for valid symbolic result codes.
- bytes
The size is the amount of data delivered to the client. Mind that this does not constitute the net object size, as headers are also counted. Also, failed requests may deliver an error page, the size of which is also logged here.
- request method
The request method to obtain an object. Please refer to section request-methods for available methods. If you turned off log_icp_queries in your configuration, you will not see (and thus unable to analyse) ICP exchanges. The PURGE method is only available, if you have an ACL for ``method purge'' enabled in your configuration file.
- URL
This column contains the URL requested. Please note that the log file may contain whitespaces for the URI. The default configuration for uri_whitespace denies whitespaces, though.
- rfc931
The eigth column may contain the ident lookups for the requesting client. Since ident lookups have performance impact, the default configuration turns ident_loookups off. If turned off, or no ident information is available, a ``-'' will be logged.
- hierarchy code
The hierarchy information consists of three items:
- Any hierarchy tag may be prefixed with TIMEOUT_, if the timeout occurs waiting for all ICP replies to return from the neighbours. The timeout is either dynamic, if the icp_query_timeout was not set, or the time configured there has run up.
- A code that explains how the request was handled, e.g. by forwarding it to a peer, or going straight to the source. Refer to section hier-codes for details on hierarchy codes and removed hierarchy codes.
- The name of the host the object was requested from. This host may be the origin site, a parent or any other peer. Also note that the hostname may be numerical.
- type
The content type of the object as seen in the HTTP reply header. Please note that ICP exchanges usually don't have any content type, and thus are logged ``-''. Also, some weird replies have content types ``:'' or even empty ones.
There may be two more columns in the access.log, if the (debug) option log_mime_headers is enabled In this case, the HTTP request headers are logged between a ``['' and a ``]'', and the HTTP reply headers are also logged between ``['' and ``]''. All control characters like CR and LF are URL-escaped, but spaces are not escaped! Parsers should watch out for this.
6.7 Squid result codes
The TCP_ codes refer to requests on the HTTP port (usually 3128). The UDP_ codes refer to requests on the ICP port (usually 3130). If ICP logging was disabled using the log_icp_queries option, no ICP replies will be logged.
The following result codes were taken from a Squid-2, compare with the log_tags struct in src/access_log.c:
- TCP_HIT
Верная копия запрошенного объекта была в кеше.
- TCP_MISS
Запрошенного объекта не было в кеше.
- TCP_REFRESH_HIT
Запрошенный объект был закеширован, но УСТАРЕЛ. IMS-запрос для этого объекта вернул "304 not modified".
- TCP_REF_FAIL_HIT
Запрошенный объект был закеширован, но УСТАРЕЛ. IMS-запрос завершен неудачно и устаревший объект был доставлен.
- TCP_REFRESH_MISS
Запрошенный объект был закеширован, но УСТАРЕЛ. IMS-запрос вернул новое содержимое.
- TCP_CLIENT_REFRESH_MISS
The client issued a "no-cache" pragma, or some analogous cache control command along with the request. Thus, the cache has to refetch the object.
- TCP_IMS_HIT
Клиент использовал IMS-запрос для объекта, который был найден в кеше свежим.
- TCP_SWAPFAIL_MISS
Объект скорее всего был в кеше, но доступа к нему нет.
- TCP_NEGATIVE_HIT
Запрос для негативно кешированных объектов типа "404 not found", for which the cache believes to know that it is inaccessible. Also refer to the explainations for negative_ttl in your squid.conf file.
- TCP_MEM_HIT
Верная копия запрошенного объекта была в кеше и в памяти, доступа к диске не производилось.
- TCP_DENIED
Доступ запрещен для этого запроса.
- TCP_OFFLINE_HIT
The requested object was retrieved from the cache during offline mode. The offline mode never validates any object, см. offline_mode в файле squid.conf.
- UDP_HIT
Верная копия запрошенного объекта была в кеше.
- UDP_MISS
Запрошенный объект отсутствует в этом кеше.
- UDP_DENIED
Доступ запрещен для этого запроса.
- UDP_INVALID
Был получен неверный запрос.
- UDP_MISS_NOFETCH
During "-Y" startup, or during frequent failures, a cache in hit only mode will return either UDP_HIT or this code. Neighbours will thus only fetch hits.
- NONE
Seen with errors and cachemgr requests.
Следующие коды больше недоступны в Squid-2:
- ERR_*
Errors are now contained in the status code.
- TCP_CLIENT_REFRESH
- TCP_SWAPFAIL
См. TCP_SWAPFAIL_MISS.
- TCP_IMS_MISS
Удалено, вместо этого используется TCP_IMS_HIT.
- UDP_HIT_OBJ
Совпавший объект больше недоступен.
- UDP_RELOADING
См. UDP_MISS_NOFETCH.
6.8 HTTP status codes
These are taken from RFC 2616 and verified for Squid. Squid-2 uses almost all codes except 307 (Temporary Redirect), 416 (Request Range Not Satisfiable), and 417 (Expectation Failed). Extra codes include 0 for a result code being unavailable, and 600 to signal an invalid header, a proxy error. Also, some definitions were added as for RFC 2518 (WebDAV). Yes, there are really two entries for status code 424, compare with http_status in src/enums.h:
000 Used mostly with UDP traffic. 100 Continue 101 Switching Protocols *102 Processing 200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content *207 Multi Status 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 303 See Other 304 Not Modified 305 Use Proxy [307 Temporary Redirect] 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Request Entity Too Large 414 Request URI Too Large 415 Unsupported Media Type [416 Request Range Not Satisfiable] [417 Expectation Failed] *424 Locked *424 Failed Dependency *433 Unprocessable Entity 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported *507 Insufficient Storage 600 Squid header parsing error
6.9 Методы запроса
Squid распознает несколько методов запросов как описано в RFC 2616. Новые версии Squid (2.2.STABLE5 и выше) также распознают расширения RFC 2518 ``HTTP Extensions for Distributed Authoring -- WEBDAV''.
method defined cachabil. meaning --------- ---------- ---------- ------------------------------------------- GET HTTP/0.9 possibly object retrieval and simple searches. HEAD HTTP/1.0 possibly metadata retrieval. POST HTTP/1.0 CC or Exp. submit data (to a program). PUT HTTP/1.1 never upload data (e.g. to a file). DELETE HTTP/1.1 never remove resource (e.g. file). TRACE HTTP/1.1 never appl. layer trace of request route. OPTIONS HTTP/1.1 never request available comm. options. CONNECT HTTP/1.1r3 never tunnel SSL connection. ICP_QUERY Squid never used for ICP based exchanges. PURGE Squid never remove object from cache. PROPFIND rfc2518 ? retrieve properties of an object. PROPATCH rfc2518 ? change properties of an object. MKCOL rfc2518 never create a new collection. MOVE rfc2518 never create a duplicate of src in dst. COPY rfc2518 never atomically move src to dst. LOCK rfc2518 never lock an object against modifications. UNLOCK rfc2518 never unlock an object.
6.10 Коды иерархий
В Squid-2 используются следующие коды иерархий:
- NONE
Для TCP HIT, неудачных TCP, запросов cachemgr и всех UDP-запросов - нет иерархической информации.
- DIRECT
Объект был получен напрямую с сервера.
- SIBLING_HIT
Объект был получен с кеша sibling, который ответил UDP_HIT.
- PARENT_HIT
Объект был запрошен из кеша parent, который ответил UDP_HIT.
- DEFAULT_PARENT
ICP-запросы не посылались. Парент был выбран, потому-что для него указано ``default'' в конфигурационном файле.
- SINGLE_PARENT
Объект был запрошен с того парента, который соответствует данному URL.
- FIRST_UP_PARENT
Объект был получен с первого парента в списке.
- NO_PARENT_DIRECT
Объект был получен напрямую с сервера, т.к. нет парента для данного URL.
- FIRST_PARENT_MISS
Объект был получен с самого быстрого парента (возможно из-за приоритета) исходя из RTT.
- CLOSEST_PARENT_MISS
Этот парент был выбран, т.к. он имеет меньшее значение RTT к запрашиваемому серверу. См. также конфигурационную closests-only для соседа.
- CLOSEST_PARENT
Выбор парента был основан на нашем собственном измерении RTT.
- CLOSEST_DIRECT
Наше собственное измерение RTT вернуло меньшее время, чем любой парент.
- NO_DIRECT_FAIL
Объект не может быть запрошен из-за настроек файервола (см. также never_direct и сопутствующие материалы), нет доступных парентов.
- SOURCE_FASTEST
Был выбран оригинальный сервер, т.к. ping достигает его бысрей всего.
- ROUNDROBIN_PARENT
Не было получено ICP-ответов ни от одного из парентов. Парент был выбран т.к. он помечен как round robin в конфиге и имеет меньшее число использования.
- CACHE_DIGEST_HIT
Сосед был выбран, потому-что cache digest сообщил о хите. Эта опция впоследствии была заменена, чтобы различать parent-ов и sibling-ов.
- CD_PARENT_HIT
Парент был выбран, потому-что cache digest предсказал хит.
- CD_SIBLING_HIT
Сиблинг был выбран, птому-что cache digest предсказал хит.
- NO_CACHE_DIGEST_DIRECT
похоже не используется?
- CARP
Сосед был выбран по CARP.
- ANY_PARENT
часть src/peer_select.c:hier_strings[].
- INVALID CODE
часть src/peer_select.c:hier_strings[].
Почти каждому из них может предшествовать 'TIMEOUT_', если 2-х секундное (по умолчанию) ожидание ICP-ответов от всех соседей оканчивается таймаутом. См. также конфигурационную опцию icp_query_timeout.
Следующие коды иерархии удалены в Squid-2:
code meaning -------------------- ------------------------------------------------- PARENT_UDP_HIT_OBJ hit objects are not longer available. SIBLING_UDP_HIT_OBJ hit objects are not longer available. SSL_PARENT_MISS SSL can now be handled by squid. FIREWALL_IP_DIRECT No special logging for hosts inside the firewall. LOCAL_IP_DIRECT No special logging for local networks.
6.11 cache/log (Squid-1.x)
Этот файл имеет очень неудачное название. Также часто это называется swap log. Это записи о каждом объекте кеша записанном на диск. Этот файл читается, когда запускается Squid, чтобы ``перегрузить'' кеш. Если вы удалите этот файл когда Squid НЕ запущен, то вы потеряете содержимое вашего кеша. Если вы удалите этот файл когда Squid УЖЕ запущен, то вы можете достаточно просто воссоздать его. Самый безопастный путь - просто завершить звапущенный процесс:
% squid -k shutdownThis will disrupt service, but at least you will have your swap log back. Другой способ - вы можете сказать squid провести ротацию логов. Это также приведет к созданию нового swap-лога.
% squid -k rotate
В Squid-1.1 он содержит шесть полей:
- fileno: The swap file number holding the object data. Это связано с именем файла в вашей файловой системе.
- timestamp: Это время последней проверки объекта на "свежесть". The time is a hexadecimal representation of Unix time.
- expires: Значение заголовка Expires в HTTP-ответе. Если заголовок Expires отсутствуе, поле будет иметь значение -2 или fffffffe. Если заголовок Expires присутствовал, но был неверен, значение будет -1 или ffffffff.
- lastmod: Значение заголовке Last-Modified в HTTP-ответе. Если отсутсвтует, то значение будет -2, если неверен, то -1.
- size: Размер объекта включая заголовок.
- url: URL для этого объекта.
6.12 swap.state (Squid-2.x)
В Squid-2 лог-файл свопа теперь называется swap.state. Это бинарный файл, содержащий контрольные суммы MD5 и поля StoreEntry. См. "Programmers Guide" для получения информации по данной теме, а также описания формата этого файла.
Если вы удалите swap.state, когда Squid запущен, просто укажите Squid сделать rotate его лог-файлов:
% squid -k rotateМожно также остановить Squid и он перезапишет этот файл перед завершением работы.
Если вы удалите swap.state, когда Squid не запущен, вы не потеряете содержимое вашего кеша. В этом случае Squid просканирует все кеш-директории и прочитает каждый свап-файл, чтобы перестроить кеш. Это может занять много времени, поэтому вы должны быть осторожны.
По умлочанию файл swap.state располагается в корне каждой cache_dir. Вы можете переместит логи в другую директорию, используя опцию cache_swap_log.
6.13 Какие лог-файлы я могу безопасно удалить?
Вы не когда не должны удалять access.log, store.log, cache.log или swap.state, когда Squid запещун. В Unix вы можете удалить открытый процессом файл. Однако место в файловой системе не будет освобождено пока процесс этот файл не закроет.
Если вы случайно удалили swap.state, когда Squid был запущен, вы можете восстановить его, следуя инструкциям из предыдущего вопроса. Если вы удалили другой лог во время работы Squid, вы не сможете его восстановить.
Правильный путь управления лог-файлами - использование ключа ``rotate''. Вам следуте делать ротацию ваших логов не менее раза в сутки. Текущий лог-файл закрывается и переименовывается с расширением в виде числа (.0, .1 и т.п.). Если у вас ест желание, можете написать свой собственный скрипт для архивации или удаления лог-файлов. Если нет, то Squid будет хранить только такое число копий каждого лог-файлов, какое указано в опции logfile_rotate. Процедура ротации лог-файлов также создает новый файл swap.state, но не оставляет пронумерованных версий старых файлов.
Чтобы сделать ротацию логов Squid, просто используйте коамнду:
squid -k rotateК примеру следующий пример демонстрирует ротацию логов в полночь при помощи cron:
0 0 * * * /usr/local/squid/bin/squid -k rotate
6.14 Как мне отключить лог-файлы в Squid?
Выключение access.log:
cache_access_log /dev/null
Выключение store.log:
cache_store_log none
Выключать cache.log - плохая идея, т.к. этот файл содержит много важной отладочной информации и сообщений о статуте. Однако, если действительно этого хотите: Выключение cache.log:
cache_log /dev/null
6.15 Мой лог становиться очень большим!
Вам необходимо делать rotate для ваших лог-файлов при помощи cron. К примеру:
0 0 * * * /usr/local/squid/bin/squid -k rotate
6.16 Управление лог-файлами
The preferred log file for analysis is the access.log file in native format. For long term evaluations, the log file should be obtained at regular intervals. Squid offers an easy to use API for rotating log files, in order that they may be moved (or removed) without disturbing the cache operations in progress. The procedures were described above.
Depending on the disk space allocated for log file storage, it is recommended to set up a cron job which rotates the log files every 24, 12, or 8 hour. You will need to set your logfile_rotate to a sufficiently large number. During a time of some idleness, you can safely transfer the log files to your analysis host in one burst.
Before transport, the log files can be compressed during off-peak time. On the analysis host, the log file are concatinated into one file, so one file for 24 hours is the yield. Also note that with log_icp_queries enabled, you might have around 1 GB of uncompressed log information per day and busy cache. Look into you cache manager info page to make an educated guess on the size of your log files.
The EU project DESIRE developed some some basic rules to obey when handling and processing log files:
- Respect the privacy of your clients when publishing results.
- Keep logs unavailable unless anonymized. Most countries have laws on privacy protection, and some even on how long you are legally allowed to keep certain kinds of information.
- Rotate and process log files at least once a day. Even if you don't process the log files, they will grow quite large, see section log-large . If you rely on processing the log files, reserve a large enough partition solely for log files.
- Keep the size in mind when processing. It might take longer to process log files than to generate them!
- Limit yourself to the numbers you are interested in. There is data
beyond your dreams available in your log file, some quite obvious, others
by combination of different views. Here are some examples for figures to
watch:
- The hosts using your cache.
- The elapsed time for HTTP requests - this is the latency the user sees. Usually, you will want to make a distinction for HITs and MISSes and overall times. Also, medians are preferred over averages.
- The requests handled per interval (e.g. second, minute or hour).
6.17 Почему я так часто получаю сообщения получаю ERR_NO_CLIENTS_BIG_OBJ?
Это сообщение значит, что запрошенный объект попал в режим ``Delete Behind'' и пользователь разорвал передачу данных. Объект попадет в режим ``Delete Behind'' если:
- Если он больше, чем maximum_object_size
- Если он скачивается с соседа, для которого установлена опция proxy-only.
6.18 Что значит ERR_LIFETIME_EXP?
Это значит, что наступил таймаут во время предачи объекта. Скорее всего the retrieval of this object was very slow (or it stalled before finishing) и пользователь пректатил обработку запроса. Однако, в зависимости от ваших установок quick_abort, Squid может продолжить попытки получить объект.Squid устанавливат максимальное значение промежутка времени на все открытые сокеты, после истечения которого обрабатываемый запрос отвергается и в лог записывается сообщение ERR_LIFETIME_EXP.
6.19 Восстановление ``потеряных'' файлов из кеша.
I've been asked to retrieve an object which was accidentally destroyed at the source for recovery. So, how do I figure out where the things are so I can copy them out and strip off the headers?
Следующий метод применим только для версии Squid-1.1:
Используйте grep, чтобы найти имя объекта (Url) в файле cache/log. Первое поле в этом файле - номер файла (целое число).
Потом найдите файл fileno-to-pathname.pl, он расположен в директории ``scripts'' исходников Squid. При использовании
perl fileno-to-pathname.pl [-c squid.conf]номер файла будет читаться из stdin, а путь/имя к нему будет выдаваться на stdout.
6.20 Can I use store.log to figure out if a response was cachable?
Sort of. You can use store.log to find out if a particular response was cached.
Cached responses are logged with the SWAPOUT tag. Uncached responses are logged with the RELEASE tag.
However, your analysis must also consider that when a cached response is removed from the cache (for example due to cache replacement) it is also logged in store.log with the RELEASE tag. To differentiate these two, you can look at the filenumber (3rd) field. When an uncachable response is released, the filenumber is FFFFFFFF (-1). Any other filenumber indicates a cached response was released.
Вперед Назад Содержание