[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

insane sumber of threads

From: Marcus Brinkmann
Subject: insane sumber of threads
Date: Mon, 1 Apr 2002 12:59:53 +0200
User-agent: Mutt/1.3.28i


I have thought about the number of threads in the filesystem.  After
compiling X on a mounted partition, there have been 3732 threads in the root
filesystem, with a whopping 85 MB RSS.

The reason why I think this is unreasonable is that a new thread is only
created when all other threads are still processing an RPC and not yet
returned to the thread pool.  However, as we use mostly synchronous RPCs,
there shouldn't be much more threads active than other threads in the
system.  However, the number of other threads in the system is more or less
constant, and smaller than ~4000.  Even the mounted filesystem I build on
has only a couple of hundred threads.

I can only think of one reason that can lead to a new thread beyond the
limit I described being created: That is when a thread sends the reply
message, it can be preempted before returning itself to the thread pool, and 
one or more new RPCs comes in.  Assuming that there are now more RPCs than
pending threads (our thread is still preempted and has not had a chance to
return itself to the pool), a new thread is created for every RPC that comes
in while the other thread is preempted.  To make it even worse, the same could
happen to the new threads, if the sheduling is unlucky enough.

My suspicion is that such a scenario is likely enough to lead to many
hundred threads created at once.  However, I don't think it is a likely
scenario once you have, say, a 1000 threads.  So this does not really
explain things.  But if the scenario above happens, it should be easy to
guard against this by throtteling the creation of threads a wee bit, to give
pending threads a chance to run and return themselve (assuming they are just
a foot away from the goal).

Next time I have a chance, I will set a limit to the number of threads
created, and let gdb suspend the filesystem at that limit.  Then I will see
what all these threads think they are doing.  Suspending the task at exactly
the point where the thread is created is the only way to find out (because
later of course you have 3500 idle threads :) If you have any idea about
this up front, I'd be happy to hear it.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]