need an upper thread cap

[Robert Collins]

when loggerhead gets busy, it keeps spawning new threads whenever there are lots of stuck ones. This is a problem because stuck threads still consume CPU and memory resources and exacerbate whatever problem is going on.

We should be able to say that there is a hard cap - say 20 - of threads, and that loggerhead never exceeds that. This would mean that if thread killing fails, we might stop servicing requests (but in that situation today we stop anyway). It would mean that when thread killing works, or busy threads eventually succeed, that service will be degraded not halted.

Bug 518689 has more discussion on the original report of this issue.

[Max Kanat-Alexander (mkanat)]

There is no current hard evidence that this would resolve (or even assist with) the problems that codebrowse experiences. Codebrowse has also been particularly stable recently.

[Robert Collins (lifeless)]

The more workers working concurrently the less efficient python servers become, there is plenty of hard evidence backing that up. We have a fixed time budget for requests; its trivial to throw lots of work at loggerhead and make it slower and slower. We also have a front end that limits the concurrent requests, but if threads are not killed, then we can still have a thundering horde appear.