`GRPC.Client.Supervisor` persistent memory growth

[dcrck]

Describe the bug

I have an application that connects to hundreds of devices and reads data from them over GRPC. I use short-lived connections for each, e.g. create a channel with GRPC.Stub.connect/2, then disconnect with GRPC.Stub.disconnect/1. For some reason, when I run :recon.proc_count(:memory, 10), GRPC.Client.Supervisor is always at the top of the list. When I call :recon.bin_leak(10) after the application runs for a while, GRPC.Client.Supervisor is also at the top of the list:

iex(5)> :recon.bin_leak(10)
[
  {#PID<0.210.0>, -1401,
   [
     GRPC.Client.Supervisor,
     {:current_function, {:gen_server, :loop, 5}},
     {:initial_call, {:proc_lib, :init_p, 5}}
   ]},
   ...
]

All my processes to retrieve this data live in short-lived supervised Tasks. Maybe this is a feature, but I don't think the process memory should be increasing like this over time? Maybe I'm doing something wrong? I don't know.

To Reproduce

1. spin up connections to a bunch of GRPC servers via GRPC.Stub.connect/1
2. make some function calls on each one
3. close the connections with GRPC.Stub.disconnect/1

Expected behavior

Binary memory is freed, at least to some degree.

Logs

Can provide if needed

Versions:

• OS: MacOS Sequoia 15.6
• Erlang: 28.3.1
• Elixir: 1.18.4
• mix.lock(grpc, gun, cowboy, cowlib):

  "grpc": {:hex, :grpc, "1.0.0-rc.1", "790336fc827f0a22521d443c1c89e941502ce1e3ef09160c7e4798b2e148b53d", [:mix], [{:castore, "~> 0.1 or ~> 1.0", [hex: :castore, repo: "hexpm", optional: true]}, {:grpc_core, "~> 1.0.0-rc.1", [hex: :grpc_core, repo: "hexpm", optional: false]}, {:gun, "~> 2.0", [hex: :gun, repo: "hexpm", optional: false]}, {:mint, "~> 1.5", [hex: :mint, repo: "hexpm", optional: false]}], "hexpm", "c60dcda2fb143769ba496bd86d33420a9e44d633555bc781deaba3668138372b"},
  "grpc_core": {:hex, :grpc_core, "1.0.0-rc.1", "d82957bca32937bb52df06596cca7550783acc139a06b70202a982ef8b59490e", [:mix], [{:googleapis, "~> 0.1.0", [hex: :googleapis, repo: "hexpm", optional: false]}, {:jason, ">= 0.0.0", [hex: :jason, repo: "hexpm", optional: false]}, {:protobuf, "~> 0.14", [hex: :protobuf, repo: "hexpm", optional: false]}, {:telemetry, "~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}], "hexpm", "c76233ea374421da562b5b022c22614e81f9cf862da93543cff93c37c085f136"},
  "gun": {:hex, :gun, "2.1.0", "b4e4cbbf3026d21981c447e9e7ca856766046eff693720ba43114d7f5de36e87", [:make, :rebar3], [{:cowlib, "2.13.0", [hex: :cowlib, repo: "hexpm", optional: false]}], "hexpm", "52fc7fc246bfc3b00e01aea1c2854c70a366348574ab50c57dfe796d24a0101d"},
  "cowlib": {:hex, :cowlib, "2.16.0", "54592074ebbbb92ee4746c8a8846e5605052f29309d3a873468d76cdf932076f", [:make, :rebar3], [], "hexpm", "7f478d80d66b747344f0ea7708c187645cfcc08b11aa424632f78e25bf05db51"},

Additional context

Add any other context about the problem here.

[dcrck]

I was able to eliminate the persistent memory growth (and various other slowdowns) by downgrading to 0.10.2. Maybe it's just an issue with the GRPC.Client implementation in 0.11 onwards?

[sleipnir]

I was able to eliminate the persistent memory growth (and various other slowdowns) by downgrading to 0.10.2. Maybe it's just an issue with the GRPC.Client implementation in 0.11 onwards?

Hi @dcrck, yes, that's likely. We'll take a look at this issue as soon as possible.