grpc-Server dies with >1400 threads

[Florian Otto [M.A.i]]

Hello together,

 

i am pretty new in using grpc, so there is a good chance for me causing the problem by myself.

 

We have a synchronous server runni ng which handles requests from multiple asynchronous clients.

Both cpp.

The handling method runs to a blocking mutex.

 

If I start a stress test, I can watch the active threads of the server process grow rapidly to about 1400 threads, causing the server to crash.  (32 bit – win10)

 

I read that grpc uses a thread-pool  for he RPCs – Is there a way to limit the number of threads?

Might there be a problem within grpc or do I get something wrong?

 

 

For any hints -  thanks in advance

Florian

 

 

 

 

 

Mit freundlichen Grüßen | Best regards

Florian Otto
Softwareentwicklung

M.A.i GmbH & Co. KG
Hummendorfer Straße 74
96317 Kronach - Neuses
Deutschland

Fax: Mobil: E-Mail: Web: Daten:

+49 9261 91000-450 +49 151 4675 7182 floria...@m-a-i.de www.m-a-i.de https://datenaustausch.m-a-i.de

Registergericht: Amtsgericht Coburg HRA 3740
Geschäftsführer: Rainer Knaak, Arthur Schwab, Hermann Fischer, Markus Orlowski

[Carl Mastrangelo]

I don't think C++ uses a thread pool, you have to provide your own.  

If you are running thousands of threads on a 32bit machine, you are probably running out of address space since each thread stack takes 1MB I think.

[Craig Tiller]

This sounds like address space exhaustion. We're looking at providing an upper bound on the number of threads created in a future update.

On Friday, September 9, 2016 at 1:32:46 AM UTC-7, Florian Otto [M.A.i] wrote: