You don't mention what troubleshooting you have done to reach your conclusion that this is due to too many RPC calls, or any details on the state of the network connections at the point of failure. I assume this error is coming about from port exhaustion due to a lack of connection pooling.
To check for port exhaustion use netstat to get the state of ports on the server. If there are an excessive number of ports listed you likely have a port exhaustion problem.
gRPC pools connections automatically, however poorly written code can stop this from functioning properly by excessively creating new gRPC channels instead of reusing existing ones. I've referenced Microsoft's documentation as it has a description of how creating new channels results in creation of a new HTTP/2 connections.
To correct this you will need to assess your code and modify it to reuse channels more appropriately.
Performance best practices with gRPC
A gRPC channel should be reused when making gRPC calls. Reusing a channel allows calls to be multiplexed through an existing HTTP/2 connection.
If a new channel is created for each gRPC call then the amount of time it takes to complete can increase significantly. Each call will require multiple network round-trips between the client and the server to create a new HTTP/2 connection:
Performance Best Practices
Always re-use stubs and channels when possible.
While doing so you might consider Unix domain sockets rather than TCP sockets. If these applications will eventual operate distributed across multiple machines you should stick to TCP sockets. If they will always run on the same machine you should consder Unix domain sockets.
How to create a GRPC service over a local socket rather then inet in scala/java
gRPC server in Python with Unix domain socket
