varnish-bugs at varnish-cache
Mar 7, 2011, 4:21 AM
Post #6 of 8
(274 views)
Permalink
|
|
Re: #501: Stats variable to monitor how many threads are actually doing something (n_wrk_busy): busy threads monitoring
[In reply to]
|
|
#501: Stats variable to monitor how many threads are actually doing something
(n_wrk_busy): busy threads monitoring
-------------------------+--------------------------------------------------
Reporter: stockrt | Owner: phk
Type: enhancement | Status: new
Priority: normal | Milestone: Varnish 3.0 dev
Component: varnishd | Version: trunk
Severity: normal | Keywords: busy threads monitoring
-------------------------+--------------------------------------------------
Changes (by kristian):
* version: 2.0 => trunk
* milestone: => Varnish 3.0 dev
Old description:
> Hi!
>
> I made this patch for implementing a new varnishstat variable, called
> 'n_wrk_busy'.
>
> With this new variable we can now know for sure how many of our active
> threads are actually doing something, so the system can be better
> dimensioned in order to know if we are getting near the max threads
> utilization: if we are, we can increase the number of max threads in
> order to instatiate more, if the system can handle more threads, if not,
> go for more hardware.
>
> This is good in the cases when we configure thread_pool_min ==
> thread_pool_max and do not have to know how many of the threads are
> actually used for something.
> I believe the same applies when we have thread_pool_min == 1 and
> thread_pool_max == MAX_WISHED. In this case we can know how many threads
> are idle (waiting for thread_pool_timeout to expire) and how many are
> actually working.
>
> This is good for monitoring and I hope this can help someone else to know
> what is happening under the hood a little better.
>
> Best regards,
>
> Rogério Schneider
New description:
Hi!
I made this patch for implementing a new varnishstat variable, called
'n_wrk_busy'.
With this new variable we can now know for sure how many of our active
threads are actually doing something, so the system can be better
dimensioned in order to know if we are getting near the max threads
utilization: if we are, we can increase the number of max threads in order
to instatiate more, if the system can handle more threads, if not, go for
more hardware.
This is good in the cases when we configure thread_pool_min ==
thread_pool_max and do not have to know how many of the threads are
actually used for something.
I believe the same applies when we have thread_pool_min == 1 and
thread_pool_max == MAX_WISHED. In this case we can know how many threads
are idle (waiting for thread_pool_timeout to expire) and how many are
actually working.
This is good for monitoring and I hope this can help someone else to know
what is happening under the hood a little better.
Best regards,
Rogério Schneider
--
Comment:
This ties in with proposed scoreboard-functionality, but is not going to
make it for 3.0.
Sorry for the horrendous response-time.... Ugh.
--
Ticket URL: <http://www.varnish-cache.org/trac/ticket/501#comment:5>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator
_______________________________________________
varnish-bugs mailing list
varnish-bugs [at] varnish-cache
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs
|
