Bug: [Excessive RAM usage reported by tmux_ram_info.sh plugin]

[druxorey]

Bug: [Excessive RAM usage reported by tmux_ram_info.sh plugin]

Describe the bug

The tmux_ram_info.sh plugin shows an excessive RAM usage when nvim is open that does not match the actual usage.

Which does not match the ram that my system is using.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'tmux'
2. Run the tmux_ram_info.sh script
3. Observe the reported RAM usage

Note: The plugin seems to work fine, but when using nvim with lazyvim, it does not count the processes correctly.

Expected behavior

The script should report accurate RAM usage.

System

• OS: Arch Linux
• Tmux Version: Latest

Possible solution

I found a possible solution but I would like to discuss it before making a PR. The original code on line 74 does this:

total_mem_kb="$(ps -o rss= -p "$pids" | paste -sd+ - | bc)"

So I changed it to this:

total_mem_kb="$(ps -o rss= -p "$pids" | awk '!seen[$0]++' | paste -sd+ | bc)"

Which shows me a better representation:

NOTE: I adjusted the rounding to better display the values, but in my solution, the rounding will remain the same.

When I run the command pstree -p "$pid" with the tmux PID, it shows a tree with multiple processes having different PIDs:

And when extracting their sizes in bytes using ps -o rss= -p "$pids" it give us this result:

 8968
10628
47736
 9632
69208
151140
151140
151140
151140
151140
151140
151140
151140
151140
151140
151140
221548
221548
221548
221548
221548
221548
221548
221548
221548
221548
221548
69208
69208
69208
69208
47736
47736
47736
47736
47736
47736
47736
47736
47736
11356
10268
 9960

However, it appears that we should not sum all of them because some PIDs are repeated. My solution was to sum only the unique values to total_mem_kb, but I am not sure if it's the best solution for this bug.

[ethancedwards8]

I like the idea of filtering duplicate PIDs. However, the command you supplied here does not work on my machines (mbair and arch linux)

[druxorey]

@ethancedwards8 Could you give me more details about what is not working? Some screenshots to see what it could be, because it worked on the machines I tried.

[Theoreticallyhugo]

somewhat off topic:
playing around with this, i ran into another interesting quirk. the ram-info widget uses free -h which reports different values to htop.....
i think it would be good to mention this quirk somewhere

[ethancedwards8]

Yeah we discovered this a few years ago. I can't find the issue for it, but it seems literally every single tool showing ram info gives a different value. There isn't really a consistent/standard way to define usage.

[druxorey]

We really have to review a lot of things regarding how the plugins are made, I was also thinking about redoing dracula.sh because it is a nightmare to modify something there, but for now this is the best solution I could think of.

I've been trying this change I made these weeks and it has worked. I can create this pr, and after that discuss how all the plugins should manage ram info.

[Theoreticallyhugo]

i dont like how some plugins have their options in the dracula.sh even though thats not at all necessary. i think we should move all plugin specific options to those plugins.
thats one obvious thing id wanna change about dracula.sh. would be very glad to hear/ see what youd like to see changed.