Not sure. It's not a memory leak, alas -- it's a memory spike, which is
OOMing my code.
After reading through the C layer some, I decided to try something simple
and stupid: I'm doing a fast force-drain of the RPC iterator to pull the
result into the Python address space, where I can monitor and
Internally, we are running ASAN test on Python tests.
If you are using Bazel, it would be as simple as --config=ASAN.
If not... then it can be challenging indeed.
The test is about 'GRPC_ARG_PER_RPC_RETRY_BUFFER_SIZE' which seems not
directly related to your case.
If the buffer is not consumed
Enabling flowctl debug tracing might show some useful log when, say, client
is not at all consuming while server keeps generating.
https://github.com/grpc/grpc/blob/master/doc/environment_variables.md
On Fri, Jul 19, 2019 at 1:03 PM Yonatan Zunger wrote:
> I have no idea what would be
I have no idea what would be involved in attaching ASAN to Python, and
suspect it may be "exciting," so I'm trying to see first if gRPC has any
monitoring capability around its buffers.
One thing I did notice while reading through the codebase was unittests
like this one
Hi Yonatan,
In gRPC Python side, the consumption of message is sequential, and won't be
kept in memory.
If you recall the batch operations, only if a message is sent to
application, will gRPC Python start another RECV_MESSAGE operation.
It's unlikely that the problem resided in Python space.
In
