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

blissify init killed by oom-kill #56

Closed
jcorporation opened this issue May 19, 2024 · 9 comments
Closed

blissify init killed by oom-kill #56

jcorporation opened this issue May 19, 2024 · 9 comments

Comments

@jcorporation
Copy link

jcorporation commented May 19, 2024

Hi,

I am the developer of myMPD and I find blissify interesting and I would play around with it.

I have tried to test it and my kernel oom-killer terminates blissify init . The machine it is running has 16GB of ram.
I thought before it was a MPD timeout...

Blissify log:

[00:01:33] ##--------------------------------------     488/16638   Analyzing /musik/file1.mp3Killed

MPD log:

client: [32] opened from 127.0.0.1:33772
client: [32] process command "list \"file\""
client: [32] command returned 0
client: [32] timeout
client: [32] closed

Kernel log:

[12630.907797] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-28d3e12a-ff9e-437c-8fe4-408f95f97967.scope,task=blissify,pid=21655,uid=1000
[12630.907937] Out of memory: Killed process 21655 (blissify) total-vm:23762156kB, anon-rss:13094704kB, file-rss:512kB, shmem-rss:0kB, UID:1000 pgtables:27192kB oom_score_adj:200
@jcorporation jcorporation changed the title MPD timeout running blissify init ~MPD timeout running blissify init~blissify init killed by oom-kill Jun 3, 2024
@jcorporation jcorporation changed the title ~MPD timeout running blissify init~blissify init killed by oom-kill blissify init killed by oom-kill Jun 3, 2024
@Polochon-street
Copy link
Owner

Hi @jcorporation!

I've tried some of what you're suggesting here #58, fix-timeout-mpd, could you clone it and tell me if it's fixing the issue for you?

@jcorporation
Copy link
Author

jcorporation commented Jun 4, 2024

Thank you! The new song fetching attempt works flawlessly.

Have you seen that I changed the initial bug report? The issue is not the song fetching, but the memory usage of blissify.

I tested it again and the memory usage increases until the kernel oom-killer kills the blissify process.

Edit: You can safely increase the search window. I use 10.000 for myMPD without issues.

@Polochon-street
Copy link
Owner

Polochon-street commented Jun 5, 2024

Ah damn, I didn't see. It still OOMs then even in fix-timeout-mpd? I'll have to take a closer look at it then.

@jcorporation
Copy link
Author

It still OOMs then even in fix-timeout-mpd?

exact. It seems you forget to free an object in a loop. The memory usage steadily grows. In the logs are also some analysis errors. I do not know if they matter, only for completeness.

@Polochon-street
Copy link
Owner

How many songs do you have? I just tried to reproduce by cloning some songs so I reach 150k songs on MPD, but the memory usage stayed the same.
If you try using --number-cores 1, does it OOM?
And if you have a lot of songs, could you try analyzing with maybe "only" 150k, to see if the problem comes from there?

I'm trying to pinpoint the issue, because I am not sure where it is coming from :)

@jcorporation
Copy link
Author

jcorporation commented Jun 5, 2024

The issue occurs after a few hundred of songs analyzed. At the moment I have no access to my laptop with the installation and access to the music directory.

If it helps: It runs the latest x86 Ubuntu version.

@Polochon-street
Copy link
Owner

I tried to reproduce, but I can't find memory steadily increasing (it just spikes from time to time but that's because we load songs directly in memory) - when you have access to your library again, could you try to run RUST_LOG=debug blissify init --number-cores 1 path/to/library, and check it it always fails around the same song?
I'm thinking maybe you have a song that fills up the RAM for some reason, either because it is large, or because there are some errors decoding it. If so, I could try and debug it using your song :)

@jcorporation
Copy link
Author

jcorporation commented Jun 7, 2024

Running blissify with --number-cores 1 fixes the issue, with 8 cores it works also. Blissify uses in the default config all cores of the system? It seems I have not enough ram for the 16 cores.

Thanks for your help!

@Polochon-street
Copy link
Owner

By default blissify uses all the cores in the system, yes :)
Songs cannot really be streamed yet, so RAM can be a pain point, but I'm working on lowering RAM consumption a bit.

Cheers!

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

No branches or pull requests

2 participants