V
vzaffiro
Does the magic number of 25 only apply to the thread pool? Does it also
apply to manually creating threads?
apply to manually creating threads?
N
Naveen
It applies only to thread pool and not to threads. The threadpool size
also can be changed from 25 to a greater number.
also can be changed from 25 to a greater number.
R
Richard Blewett [DevelopMentor]
Naveen said:
The default cap in the thread pool is 25 thread *per processor* so on a 2
processor machine it defaults to 50. However, in v2.0 you can change the
number of threads the thread pool caps to via the ThreadPool.SetMaxThreads()
call.
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
C
Cowboy \(Gregory A. Beamer\)
25 is just a default and you can configure it. As for your own threads, you
can keep creating as many as you want ... until you crash the machine, that
is.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
can keep creating as many as you want ... until you crash the machine, that
is.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
G
Greg Young
<splittinghairs>
you will run out of stack space long before you crash the machine on most
machines
A process in windows is generally only allowed 2 gb of memory ... by default
every thread that you start up uses 1 mb of stack space. As such the maximum
would be 2000 You can however set the stack size of threads (in 1.x via a
direct call to CreateThread, in 2.0 an overloaded constructor)
</splittinghairs>
Cheers,
Greg
you will run out of stack space long before you crash the machine on most
machines
A process in windows is generally only allowed 2 gb of memory ... by default
every thread that you start up uses 1 mb of stack space. As such the maximum
would be 2000
You can however set the stack size of threads (in 1.x via adirect call to CreateThread, in 2.0 an overloaded constructor)
</splittinghairs>
Cheers,
Greg
A
Alvin Bruney
you will run out of stack space long before you crash the machine on most
the out of memory exception is thrown.
--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------
Nope. As I demonstrated earlier this week, the machine crashes long before
the out of memory exception is thrown.
--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------
M
Michael Nemtsev
Hello Cowboy (Gregory A. Beamer),
Take into accout that they say the 25 is the maximum number if thead that
can give u visible performance.
Increasing that number of thread don't give u any advantage, notwithstanding
the system size and complexity.
C> 25 is just a default and you can configure it. As for your own
C> threads, you can keep creating as many as you want ... until you
C> crash the machine, that is.
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
Take into accout that they say the 25 is the maximum number if thead that
can give u visible performance.
Increasing that number of thread don't give u any advantage, notwithstanding
the system size and complexity.
C> 25 is just a default and you can configure it. As for your own
C> threads, you can keep creating as many as you want ... until you
C> crash the machine, that is.
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
R
Richard Blewett [DevelopMentor]
Michael Nemtsev said:
I think thats possibly a bit of a generalisation. For example, ASP.NET
increases this value to 50 by default. Surely it depends on what the
appliction is doing, how much contention there is for shared resources and
that kind of thing.
For example, if I had a remoting server (remoting dispatches calls on thread
pool threads) and those remoting calls were accessing discrete parts of a
database or separate files on the file system why would limiting the app to
25 concurrent calls be a good thing and what would prevent those calls from
being multiplexed higher by increasing the maxiumum umber of threads in the
pool?
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
M
Michael Nemtsev
Hello Richard Blewett [DevelopMentor]" richard at nospam dotnetconsult dot
co dot uk,
Yep, it's only generalization. AFAIK they choose number 25 as a golden mean.
But as you say, everything depends on our own project. We need to measure
the cost of thread's context switch and decide whether is there any advantage
of increasing the number of our thread.
R> I think thats possibly a bit of a generalisation. For example,
R> ASP.NET increases this value to 50 by default. Surely it depends on
R> what the appliction is doing, how much contention there is for shared
R> resources and that kind of thing.
R>
R> For example, if I had a remoting server (remoting dispatches calls on
R> thread pool threads) and those remoting calls were accessing discrete
R> parts of a database or separate files on the file system why would
R> limiting the app to 25 concurrent calls be a good thing and what
R> would prevent those calls from being multiplexed higher by increasing
R> the maxiumum umber of threads in the pool?
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
co dot uk,
Yep, it's only generalization. AFAIK they choose number 25 as a golden mean.
But as you say, everything depends on our own project. We need to measure
the cost of thread's context switch and decide whether is there any advantage
of increasing the number of our thread.
R> I think thats possibly a bit of a generalisation. For example,
R> ASP.NET increases this value to 50 by default. Surely it depends on
R> what the appliction is doing, how much contention there is for shared
R> resources and that kind of thing.
R>
R> For example, if I had a remoting server (remoting dispatches calls on
R> thread pool threads) and those remoting calls were accessing discrete
R> parts of a database or separate files on the file system why would
R> limiting the app to 25 concurrent calls be a good thing and what
R> would prevent those calls from being multiplexed higher by increasing
R> the maxiumum umber of threads in the pool?
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
W
Willy Denoyette [MVP]
"Richard Blewett [DevelopMentor]" <richard at nospam dotnetconsult dot co
dot uk> wrote in message | | > Hello Cowboy (Gregory A. Beamer),
| >
| > Take into accout that they say the 25 is the maximum number if thead
that
| > can give u visible performance.
| > Increasing that number of thread don't give u any advantage,
| > notwithstanding the system size and complexity.
|
| I think thats possibly a bit of a generalisation. For example, ASP.NET
| increases this value to 50 by default. Surely it depends on what the
| appliction is doing, how much contention there is for shared resources and
| that kind of thing.
|
| For example, if I had a remoting server (remoting dispatches calls on
thread
| pool threads) and those remoting calls were accessing discrete parts of a
| database or separate files on the file system why would limiting the app
to
| 25 concurrent calls be a good thing and what would prevent those calls
from
| being multiplexed higher by increasing the maxiumum umber of threads in
the
| pool?
|
| Regards
|
| Richard Blewett - DevelopMentor
| http://www.dotnetconsult.co.uk/weblog
| http://www.dotnetconsult.co.uk
|
|
Richard,
In the remoting scenario (and ASP.NET) , the requests are handled by the
Completion port threads not on the worker threads from the thread pool.
You can check this by calling ThreadPool.GetAvailableThreads.
In a remote server application of mine where I have 50 clients
simultaneously calling a remoting server, I get the following values for the
thread pool threads:
Max worker threads = 50, available = 50
Max I/O threads = 1000, available = 995
Note that this was taken on a dual CPU box (hence the 50 workers), see there
are no worker threads taken, the number of IOCP threads varies between 2 and
6, but this highly depends on the task, but I never saw more than 10-12 IOCP
threads running on a dual CPU box.
Willy.
dot uk> wrote in message | | > Hello Cowboy (Gregory A. Beamer),
| >
| > Take into accout that they say the 25 is the maximum number if thead
that
| > can give u visible performance.
| > Increasing that number of thread don't give u any advantage,
| > notwithstanding the system size and complexity.
|
| I think thats possibly a bit of a generalisation. For example, ASP.NET
| increases this value to 50 by default. Surely it depends on what the
| appliction is doing, how much contention there is for shared resources and
| that kind of thing.
|
| For example, if I had a remoting server (remoting dispatches calls on
thread
| pool threads) and those remoting calls were accessing discrete parts of a
| database or separate files on the file system why would limiting the app
to
| 25 concurrent calls be a good thing and what would prevent those calls
from
| being multiplexed higher by increasing the maxiumum umber of threads in
the
| pool?
|
| Regards
|
| Richard Blewett - DevelopMentor
| http://www.dotnetconsult.co.uk/weblog
| http://www.dotnetconsult.co.uk
|
|
Richard,
In the remoting scenario (and ASP.NET) , the requests are handled by the
Completion port threads not on the worker threads from the thread pool.
You can check this by calling ThreadPool.GetAvailableThreads.
In a remote server application of mine where I have 50 clients
simultaneously calling a remoting server, I get the following values for the
thread pool threads:
Max worker threads = 50, available = 50
Max I/O threads = 1000, available = 995
Note that this was taken on a dual CPU box (hence the 50 workers), see there
are no worker threads taken, the number of IOCP threads varies between 2 and
6, but this highly depends on the task, but I never saw more than 10-12 IOCP
threads running on a dual CPU box.
Willy.
R
Richard Blewett [DevelopMentor]
Richard,
Ahh interesting - I knew it was handled by the threadpool but I always
assumed it was worker threads (although i guess its up to the channel) - thx
for the clarification.
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
Ahh interesting - I knew it was handled by the threadpool but I always
assumed it was worker threads (although i guess its up to the channel) - thx
for the clarification.
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
W
Willy Denoyette [MVP]
"Richard Blewett [DevelopMentor]" <richard at nospam dotnetconsult dot co
dot uk> wrote in message |> Richard,
| > In the remoting scenario (and ASP.NET) , the requests are handled by the
| > Completion port threads not on the worker threads from the thread pool.
| > You can check this by calling ThreadPool.GetAvailableThreads.
| > In a remote server application of mine where I have 50 clients
| > simultaneously calling a remoting server, I get the following values for
| > the
| > thread pool threads:
| >
| > Max worker threads = 50, available = 50
| > Max I/O threads = 1000, available = 995
| >
| > Note that this was taken on a dual CPU box (hence the 50 workers), see
| > there
| > are no worker threads taken, the number of IOCP threads varies between 2
| > and
| > 6, but this highly depends on the task, but I never saw more than 10-12
| > IOCP
| > threads running on a dual CPU box.
| >
| > Willy.
| >
| >
|
| Ahh interesting - I knew it was handled by the threadpool but I always
| assumed it was worker threads (although i guess its up to the channel) -
thx
| for the clarification.
|
Well, I'm using tcp (across the network) and ipc (cross-process)channels and
both are using IOCP threads to handle the requests, this is quite normal as
both use the asynchronous I-O support mapped on CP's in .NET.
Note that in a tcp scenario, the number of CP threads used highly depend on
the number of CPU's and their speed, the network speed and topology and the
actual network load and the call payload.
Willy.
dot uk> wrote in message |> Richard,
| > In the remoting scenario (and ASP.NET) , the requests are handled by the
| > Completion port threads not on the worker threads from the thread pool.
| > You can check this by calling ThreadPool.GetAvailableThreads.
| > In a remote server application of mine where I have 50 clients
| > simultaneously calling a remoting server, I get the following values for
| > the
| > thread pool threads:
| >
| > Max worker threads = 50, available = 50
| > Max I/O threads = 1000, available = 995
| >
| > Note that this was taken on a dual CPU box (hence the 50 workers), see
| > there
| > are no worker threads taken, the number of IOCP threads varies between 2
| > and
| > 6, but this highly depends on the task, but I never saw more than 10-12
| > IOCP
| > threads running on a dual CPU box.
| >
| > Willy.
| >
| >
|
| Ahh interesting - I knew it was handled by the threadpool but I always
| assumed it was worker threads (although i guess its up to the channel) -
thx
| for the clarification.
|
Well, I'm using tcp (across the network) and ipc (cross-process)channels and
both are using IOCP threads to handle the requests, this is quite normal as
both use the asynchronous I-O support mapped on CP's in .NET.
Note that in a tcp scenario, the number of CP threads used highly depend on
the number of CPU's and their speed, the network speed and topology and the
actual network load and the call payload.
Willy.
C
Cowboy \(Gregory A. Beamer\)
That was the reason for the smiley.
As for memory, you can, if you want, increase the default memory space. In
most cases, it is not advised, of course.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
As for memory, you can, if you want, increase the default memory space. In
most cases, it is not advised, of course.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
C
Cowboy \(Gregory A. Beamer\)
How does one get an out of memory error anyway?
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
Alvin Bruney said:Nope. As I demonstrated earlier this week, the machine crashes long before
the out of memory exception is thrown.
--
________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------
Greg Young said:<splittinghairs>
you will run out of stack space long before you crash the machine on most
machines
A process in windows is generally only allowed 2 gb of memory ... by
default every thread that you start up uses 1 mb of stack space. As such
the maximum would be 2000
threads (in 1.x via a direct call to CreateThread, in 2.0 an overloaded
constructor)
</splittinghairs>
Cheers,
Greg
C
Cowboy \(Gregory A. Beamer\)
The number of threads is configurable, as systems are different. In general,
you try not to run a bunch of long running processes at the same time, so 25
is more than enough in the majority of applications.
As for performance, the number of threads is not generally the big perf
issue in multi-threaded applications, unless you lack mutual exclusivity and
start contending for the same resource. Considering that many people fail to
prevent contention, it is a possibility.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************
you try not to run a bunch of long running processes at the same time, so 25
is more than enough in the majority of applications.
As for performance, the number of threads is not generally the big perf
issue in multi-threaded applications, unless you lack mutual exclusivity and
start contending for the same resource. Considering that many people fail to
prevent contention, it is a possibility.
--
Gregory A. Beamer
*************************************************
Think Outside the Box!
*************************************************