On 19 Sep 2006 at 13:17, Adrian Chadd wrote:
> Here's the hourly snapshot. 
> 
> Adrian
> 
> Last 1 hour averages: (Cumulated time: 25411206816740, 2782.06 sec)
> 
>           Probe Name            Events   cumulated time best case average worst case  Rate / sec % in int
> 
> PROF_UNACCOUNTED               105984696  1728110104996         0   16305   424549192   38095.75    6.801
> PROF_OVERHEAD                     115170       18666044         0     162      212816      41.40    0.000
> HttpStateData_readReply          6748802 20584289534326         0 3050065 23144291000    2425.83   81.005
> StoreEntry_write                82448181 19892984791130         0  241278 23142919280   29635.65   78.284
> storeGetMemSpace                82448181 18827597315536         0  228356 23142884908   29635.65   74.092
> comm_check_incoming              1746752  1530441372606         0  876164    92138904     627.86    6.023
> comm_handle_ready_fd             1652867  1265826211860         0  765836   233867732     594.12    4.981
> HttpStateData_processReplyBody   6747441  1252785308450         0  185668  9434162500    2425.34    4.930
> MemObject_write                 82448181  1023697835718         0   12416    87664104   29635.65    4.029
> storeWriteComplete              82448181   684813646988         0    8305    46559868   29635.65    2.695
> 
Is that all? or did you paste only part of probes?
When I used it on my prod caches, I enabled quite alot
more probes. When the profiling feature was included,
there were other concurrent changes (eg chunked mempools)
and in submitted patch many probes got left out.
Since then quite alot of changes have happened, so I'd
suggest to look at the gprof stats to decide what funcs
to probe with hires prof and add them. 
Also review the probes already there - you'd want to make
sure a probe isn't left "running" at any function exit
point - this would lead to accounting to a probe sections
of code incorrectly.
There's something fishy with "best case" timers. They
shouldn't be zero, ever. Ditto "worst case" - they *can*
get high due to task switches, but your worst cases look
way too high, on P4 2.6G there should be 2.6G ticks per
second. Your worst case looks like probes have been
running for 8.9secs straight, seems unlikely.
So there seems to be a need to get hires profiling
uptodate with current squid code base.
Unfortunately, I can't participate for now, my company
has been restructured and caching has been thrown out, so
I don't have any suitable platform at the moment.. ;(
------------------------------------
 Andres Kroonmaa
 Elion
Received on Tue Sep 19 2006 - 05:15:40 MDT
This archive was generated by hypermail pre-2.1.9 : Sun Oct 01 2006 - 12:00:06 MDT