Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8.1.0 prerelease used 59gb of memory #8485

Closed
balupton opened this issue Mar 7, 2025 · 12 comments · Fixed by #8495 or #8505
Closed

8.1.0 prerelease used 59gb of memory #8485

balupton opened this issue Mar 7, 2025 · 12 comments · Fixed by #8495 or #8505
Assignees
Milestone

Comments

@balupton
Copy link

balupton commented Mar 7, 2025

After upgrading to the 8.1.0 prerelease from 8.0.7 on a m1 Mac mini running the latest macOS resulted in the force quit out of memory macOS modal after about an hour of use, in which tribler was the culprit at 59gb of memory on a 16gb of ram machine. I had to force quit it from that modal as the menu bar icon was unresponsive.

I have I guess 200 torrents in which half of them are completed.

Haven't reopened it since the force quit.

Let me know what steps are needed to send the logs.

@teddyrogers
Copy link

I have noticed this on Windows too. Last time I check Tribler was using 5.8GB.

@absolutep
Copy link

absolutep commented Mar 8, 2025

After upgrading to the 8.1.0 prerelease from 8.0.7 on a m1 Mac mini running the latest macOS resulted in the force quit out of memory macOS modal after about an hour of use, in which tribler was the culprit at 59gb of memory on a 16gb of ram machine. I had to force quit it from that modal as the menu bar icon was unresponsive.

I have I guess 200 torrents in which half of them are completed.

Haven't reopened it since the force quit.

Let me know what steps are needed to send the logs.

Did you change Hops?

This happened with me [sudden rise in size of Tribler folder] also.

I changed Hops of my torrents and then suddenly my Tribler folder was equivalent to 80 GB.

All these torrents of mine, were already present in BiglyBT, so when I opened BiglyBT - all those torrents suffered disk error & automatically deleted themselves.

I have put them on redownload but some torrents were very obscure - hopefully I can get them back.

I think this error is related to this = #8483

But who knows

@teddyrogers
Copy link

I think my issue may have been related to the debug logs. When the logs are open it is consuming excessive amounts of memory in the browser, not specific to the Tribler process. I have seen it use up to over 8GB of memory.

@balupton
Copy link
Author

balupton commented Mar 8, 2025

No change in hops, they have all been 3 hops.

I did not have the web client open at the time.

@teddyrogers
Copy link

I checked Tribler process today and it is reporting 7.2GB....

Image

Unfortunately I restarted Tribler before checking where the memory is being used.

@mouse-the
Copy link
Contributor

mouse-the commented Mar 9, 2025

Since upgrading to 8.1.0 I am also seeing uncontrolled memory usage.
Debian Linux, 24g ram, 1g swap. Github .deb 8.1.0
I do have a 3 digit number of downloads, all but ~10 completed.
This morning I managed to observe something that probably also happened twice yesterday.
In short, after running unattended for 6 hours, tribler had used all the memory.
kswapd was running the CPU hard,
tribler had more than half the ram and 60g of virt
I think the KDE lockscreen did not manage to come up until tribler shut down.

I have tribler's output redirected to /dev/null to prevent it from filling my root partition, so I have not been able to look for hints there.

Based on casually observing top while writing this, tribler seems to be steadily consuming memory, maybe on the order of a gig per hour. ...and already 42g of virt...

Oh, poking around in the journal confirms the kernel killed tribler:

Mar 09 03:03:21 mouse23 systemd[1139]: Started app-org.tribler.Tribler-4cd2900cefb443c68466c7f5074053ed.scope - Tribler - P2P /Bittorrent/Youtube client.
Mar 09 11:37:19 mouse23 kernel: [ 25337] 1000 25337 15914039 3590121 35635200 5895 200 tribler
Mar 09 11:37:19 mouse23 kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/app-org.tribler.Tribler-4cd2900cefb443c68466c7f5074053ed.scope,task=tribler,pid=25337,uid=1000
Mar 09 11:37:19 mouse23 kernel: Out of memory: Killed process 25337 (tribler) total-vm:63656156kB, anon-rss:14360476kB, file-rss:0kB, shmem-rss:8kB, UID:1000 pgtables:34800kB oom_score_adj:200
Mar 09 11:37:18 mouse23 systemd[1139]: app-org.tribler.Tribler-4cd2900cefb443c68466c7f5074053ed.scope: A process of this unit has been killed by the OOM killer.
Mar 09 11:37:20 mouse23 kernel: oom_reaper: reaped process 25337 (tribler), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Mar 09 11:37:20 mouse23 systemd[1139]: app-org.tribler.Tribler-4cd2900cefb443c68466c7f5074053ed.scope: Failed with result 'oom-kill'.
Mar 09 11:37:20 mouse23 systemd[1139]: app-org.tribler.Tribler-4cd2900cefb443c68466c7f5074053ed.scope: Consumed 4h 32min 11.684s CPU time.

...and another glance at top suggests that the memory has leveled off for now...
Let me know if I can help.

Update from 2 hours later; the memory use has gone down a bit, so it is not a simple case of memory use steadily increasing...

@teddyrogers
Copy link

Logged on today, checked Task Manager and Tribler was using 11.5GB memory. Took a screenshot...

Image

...then went to check process memory usage to diagnose and it dropped back down to 1.2GB???

@qstokkink
Copy link
Contributor

Thanks for the input everyone. I think we hit this bug (inside our libtorrent dependency, which has been updated to support Bittorrent v2): arvidn/libtorrent#6667

If I read that (massive) issue correctly, the default disk writing mode of mmap is causing these issues. We should be able to fix this in Tribler by setting the default disk writing mode (disk_write_mode) to mmap_write_mode_t.always_pwrite. We'll try that for the next pre-release.

@qstokkink qstokkink added this to the 8.1.1 milestone Mar 10, 2025
@qstokkink qstokkink self-assigned this Mar 10, 2025
@teddyrogers
Copy link

@qstokkink I installed Tribler 8.0.7 and ran some tests in comparison to 8.1.0 and it looks like the current version is mapping the torrent data files to memory. I don't see the mapping occurring in Tribler 8.0.7. I think this also explains why I was seeing memory usage spiking and then dropping off...

Image

@HanabishiRecca
Copy link

disk_write_mode only affects writes. Seeding would still hog the memory.
In qBittorrent we use this workaround: qbittorrent/qBittorrent#21300

@qstokkink
Copy link
Contributor

@HanabishiRecca thanks for the help! Setting the mmap_file_size_cutoff to the max int was not quite obvious to me from the docs. I imagine that took quite a bit of effort to find.

Re-opening this issue until the above is implemented.

@qstokkink qstokkink reopened this Mar 11, 2025
@qstokkink qstokkink modified the milestones: 8.1.1, 8.1.2 Mar 11, 2025
@teddyrogers
Copy link

Tribler 8.1.1, there is a large amount of memory pages being allocated for torrent data files. I believe this to be a continuation of #8485.

A current Tribler session is using 8.95GB of memory...

Image

...here are the commits to Triblers memory map...

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

6 participants