LiveDebugger is making the system run slow and memory is growing rapidly

[allenwyma]

Bug Description

live_debugger on 2 different systems is producing different effects.

On my system, it's running fine, but on their system live_debugger's memory is growing beyond 25GB and causing slow runtime.

For instance, on my computer, it's taking about 4ms to run a handle_event call, when it's taking 300-400ms for the same call on their machine.

Actual Behavior

On my system, it's running fine, but on their system live_debugger's memory is growing beyond 25GB and causing slow runtime.

For instance, on my computer, it's taking about 4ms to run a handle_event call, when it's taking 300-400ms for the same call on their machine.

Expected Behavior

Should be the same for performance.

Steps to Reproduce

This is hard to debug as we are running the same system, he's using an M3 max and I"m using an M2 max cpu.

Elixir version with Erlang/OTP

1.19.5

LiveDebugger version

0.6.1

Phoenix version

1.8.5

Phoenix LiveView version

1.1.27

Operating system

macos

Browser(s)

firefox and google chrome

[srzeszut]

Hey, thanks for the report. Could you double-check if the garbage collection option is enabled in live_debugger and if possible let us know the exact steps to reproduce the memory spike?

[allenwyma]

Hey, thanks for the report. Could you double-check if the garbage collection option is enabled in live_debugger and if possible let us know the exact steps to reproduce the memory spike?

how can i check this?

Also the codebase is the same between mine and his computer in terms of the project.

[srzeszut]

There is an option in settings to disable garbage collection.

Make sure you have garbage collection enabled.

Does this happen every time, or was it just a one time event that you can't reproduce?

Could you also share some details about the assigns size? Are you seeing a large amount of traces being generated in this case?

[kraleppa]

Also, if you can share:

1. Approximate number of LiveView processes when it’s slow
2. Does it happen only if LiveDebugger is inspecting node and/or tracing is enabled?

[AngyL75]

Hi, Garbage collection is ON on my computer.

iex(2)> LiveDebugger.API.SettingsStorage.get(:garbage_collection)
true

The memory issue is not new. In fact, on this specific project it has been like that for more than 5 months, with (1) phx.server being very slow at recompiling code, (2) eventually crashing when I was doing local test and (3) all interactions using some javascript being 100 times slower and page load also being slower and slower.

So, yes, it happens all the time, but only on my machine, NOT on @allenwyma's machine.... with same project.

[AngyL75]

Also, if you can share:
1. Approximate number of LiveView processes when it’s slow
2. Does it happen only if LiveDebugger is inspecting node and/or tracing is enabled?

We usually have 1 or 2 liveviews at the same on every page.

our configuration file is
config :live_debugger, browser_features?: true

in mix.exs, we have
{:live_debugger, "~> 0.1", only: [:dev]},

[kraleppa]

Thanks, for your responses, but we still need some more since we completely cannot reproduce it:

1. Could you please confirm you’re running the exact same LiveDebugger dependency/runtime? Can you provide the output of:

Application.spec(:live_debugger, :vsn)

2. Can you paste the LiveDebugger settings that are actually used at runtime (from its DETS settings storage)?

LiveDebugger.API.SettingsStorage.get_all()

3. Can you also paste the config values from the application env:

Application.get_all_env(:live_debugger)

Also, can you confirm that the issue reproduces on the same commit/tag of your project as @allenwyma (and that you’re using the same Elixir + OTP versions)?

[CuriousCurmudgeon]

First, thanks for the fantastic project! I appreciated the improved tooling it provides for debugging.

We are seeing the same issue on our project. We can reliably reproduce it on a live view in our app that refreshes a lot for one use case. We originally thought it was related to an OTP upgrade, but we confirmed that it happens on both OTP 27.3.4 and OTP 28.4.1. We also confirmed on both macOS and Linux. I don't remember my co-worker's Linux flavor. I can get that if needed.

Here is the output to the above questions. We upgraded to 0.7.0 while debugging this, but also saw the issue on 0.6.0.

$ Application.spec(:live_debugger, :vsn)
~c"0.7.0"

$ LiveDebugger.API.SettingsStorage.get_all()
%{
  garbage_collection: true,
  debug_button: true,
  dead_liveviews: false,
  dead_view_mode: true,
  highlight_in_browser: true,
  tracing_enabled_on_start: true
}

$ Application.get_all_env(:live_debugger)
[
  {:adapter, Phoenix.Endpoint.Cowboy2Adapter},
  {:debug_button?, false},
  {LiveDebugger.App.Web.Endpoint,
   [
     http: [ip: {127, 0, 0, 1}, port: 4007],
     secret_key_base: "DEFAULT_SECRET_KEY_BASE_1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcd",
     live_view: [signing_salt: "live_debugger_signing_salt"],
     adapter: Phoenix.Endpoint.Cowboy2Adapter,
     live_reload: [],
     drainer: [shutdown: 1000]
   ]},
  {:port, 4007},
  {:live_debugger_tags,
   %Phoenix.LiveView.Rendered{
     static: ["<!-- <LiveDebugger.Client.ConfigComponent.live_debugger_tags> lib/live_debugger/client/config_component.ex:18 (live_debugger) --><meta data-phx-loc=\"19\" name=\"live-debugger-config\"",
      "", "", ">\n",
      "<!-- </LiveDebugger.Client.ConfigComponent.live_debugger_tags> -->"],
     dynamic: [#Function](https://github.com/software-mansion/live-debugger/issues/956#Function)<0.59460720/1 in LiveDebugger.Client.ConfigComponent."live_debugger_tags (overridable 1)"/1>,
     fingerprint: 145856113719373722565957671020223029354,
     root: false,
     caller: :not_available
   }}
]

[kraleppa]

Hi @CuriousCurmudgeon, glad to hear you like it 😄

So the problem is that we cannot reproduce this case - we’re running LiveDebugger across several different apps daily during development, and we haven't encountered this issue even once.

I need more details to understand what is the root cause of this issue and it'd be extremely helpful if you could provide more context about your case (or even a source code if possible):

1. Does it happen only in one particular LiveView? You mentioned the LiveView refreshes a lot. Is this a full browser refresh, or is the view handling a high frequency of incoming events/messages that trigger constant re-renders?
2. How large are the assigns in this view? (You can check the size in the "Assigns" section if the debugger stays open long enough).
3. How many LiveViews and LiveComponents are active on this page?
4. Are you using any newer features like assign_async, handle_async, temporary assigns, or streams in this particular view?
5. Does the crash/issue happen only when the LiveDebugger window/UI is open, or does it happen even when it’s just enabled in the background?
6. If the window is open: which tab are you usually on (Node Inspector, Traces, Resources)? Is "Tracing" enabled when it happens?
7. If you have Phoenix LiveDashboard installed, could you share screenshots of the Home (Memory usage section), ETS, and Processes sections when the issue occurs (sorted by memory usage)? This would be a massive help in spotting memory leaks or process bottlenecks. (Check the screenshots I attached as a reference)

Also, to have the full picture - could you provide version of phoenix, liveview, and elixir?

I'd really like to help you guys, but we don't know where to look for at this moment

[CuriousCurmudgeon]

Answers below. The core issue is that we do some Very Bad Things™ in this LiveView that cause it to churn through large assigns and hold too much data in memory. The page updates 5-6 times per second in this scenario. My assumption is that this is doing something with the assigns history feature in live debugger to explode memory usage.

Ultimately, this is an us problem. We shouldn't be using LiveView like this on this page. We just haven't gotten around to fixing it.

I discovered the issue while doing a performance regression on our app after upgrading our core dependencies. This testing was done on

• OTP 28.4.1
• Elixir 1.19.5
• Phoenix 1.8.5
• LiveView 1.1.27
• LiveDebugger 0.7.0

I went back and saw that the issue was also happening before the upgrades on

• OTP 27.4.3
• Elixir 1.19.2
• Phoenix 1.7.21
• LiveView 1.0.18
• LiveDebugger 0.6.0

1. Does it happen only in one particular LiveView? You mentioned the LiveView refreshes a lot. Is this a full browser refresh, or is the view handling a high frequency of incoming events/messages that trigger constant re-renders?

We have only noticed it on one live view when using a feature in our app that triggers 5-6 handle_event callbacks per second. These all trigger a render. What we're doing is almost certainly a live view anti-pattern, but we haven't had time to rearchitect.

2. How large are the assigns in this view? (You can check the size in the "Assigns" section if the debugger stays open long enough).

Assigns size starts at 3.4MB

3. How many LiveViews and LiveComponents are active on this page?

One live view and two live components

4. Are you using any newer features like assign_async, handle_async, temporary assigns, or streams in this particular view?

This particular live view only uses streams. However, it doesn't use them correctly, so we still end up with 500 item list in assigns. That's a big contributor to the 3.4MB starting assigns size.

5. Does the crash/issue happen only when the LiveDebugger window/UI is open, or does it happen even when it’s just enabled in the background?

Still happens just when enabled in the background. When I start using the feature that causes all the handle_event callbacks, memory usage will explode until eventually macOS kills the beam process.

6. If the window is open: which tab are you usually on (Node Inspector, Traces, Resources)? Is "Tracing" enabled when it happens?

Happens either way

7. If you have Phoenix LiveDashboard installed, could you share screenshots of the Home (Memory usage section), ETS, and Processes sections when the issue occurs (sorted by memory usage)? This would be a massive help in spotting memory leaks or process bottlenecks. (Check the screenshots I attached as a reference)

These were the best screenshots I could get as I let the app run through a large data set. My machine gets bogged down until eventually macOS kills the process for using too much memory. The numbers won't quite add up correctly since memory shoots up so fast as I'm trying to get screenshots.

macOS says the beam process was trying to use over 140GB of memory before it got killed.

[kraleppa]

@CuriousCurmudgeon that's awesome - this will help us a lot! Really appreciate that 😄