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


Reply via email to