> Hello Amos, squid gurus and mortals, this is in part in reference to a
> message from lorenor. I don't want to top-post lorenor so that being said
> I would just like to say the absolute best way for a lot of folks to
> <debug> their squid-cache issues is to turn on the debug_options. The
> squid-cache debug_options default makes sense for beginning the use of
> squid-cache but sorely needs attention if the user plans to make
> productive use of the squid-cache. In light of the previous sentence I
> have come up with a so-called optimal debug_options list for my instance
> of squid. The term: optimal means to leave or reduce the debug_options
> categories that are not needed or have no interest for the target squid
> user. The chances of a universal optimal debug_options is not possible as
> this needs to change for each user's instance of squid. I have listed my
> debug_options below and I have a few questions for such a list:
>
> 1. What or how does tuning the debug_options affect squid reporting tools
> such as: SARG?
AFAIK, it does not affect SARG and most tools, which only process the
access.log. Some tools which process the cache.log and warn admin about
problems might require certain levels for certain warnings. I'm not aware
of any such tools being publicly available, if people know of one, please
speak up.
> 2. What or which sections have been left out?
see doc/debug-sections.txt for a list of the existing sections.
> 3. Which sections have the wrong debug level? <some section>,1-9?
There is no consistent use of debug levels: <section>,2+ at present its
up to the code author and later bug fixers to select any given message and
what level it has.
> 4. Why was section 24 skipped?
As you can probably see by looking at the list of sections the number
selection has long since lost any pattern it may once have had for
section:meaning maps.
When a new section is needed, the code author selects one they want, makes
a request and its reservation goes up for discussion with the main
developers.
>
> **************************************
> debug_options 0,2 1,3 3,3 4,2 9,1 11,3 12,3 14,3 16,3 17,3 18,3 20,2 22,3
> 23,3 25,3 27,2 28,3 30,2 31,3 33,3 34,2 35,3 37,3 38,2 39,2 40,3 41,2 42,2
> 43,2 45,2 46,3 48,3 50,2 51,2 52,3 54,2 55,3 56,3 57,3 58,3 61,3 62,2 64,3
> 65,3 66,3 67,2 68,2 69,2 70,2 71,2 73,3 74,3 75,2 76,2 78,2 79,2 81,2 84,2
> 85,3 87,3 88,3 89,2 90,3 92,2 93,4
>
The list depends entirely on what you mean by 'optimal'. There are several
groups of users with different needs regarding cache.log.
level 0 - critical messages with absolute minimal logging traffic to slow
squid down. For very high performance people.
level 1 - important messages and warnings. For most people who can afford
the very minor extra disk logging time and space. Or people upgrading
squid might find the new warnings useful.
level 2-6 most other informative things. The output here is mostly
section specific. Recommended to be set only on the required sections
when trying to trace actual code paths through squid towards a bug, or
something weird thats happening. Some few sections (IO types and garbage
collection) produce a LOT of data here.
level 7-9 mostly used for full data dumps of requests (headers, object
content, buffer content, the lot). sections which use these levels
definitely produce a LOT of data here.
Every now and again we have an argument amongst the developers about
formalizing the levels and how they are used. The last round got level 0-1
assigned a fixed meaning as I mention above. If you can come up with a
good idea about how the rest of the levels might be used in squid submit
the proposal to squid-dev.
Amos
Received on Sun Feb 22 2009 - 22:25:17 MST
This archive was generated by hypermail 2.2.0 : Mon Feb 23 2009 - 12:00:01 MST