blissify init killed by oom-kill

[jcorporation]

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/user@1000.service/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

[Polochon-street]

Hi @jcorporation!

I've tried some of what you're suggesting here https://github.com/Polochon-street/blissify-rs/pull/58, fix-timeout-mpd, could you clone it and tell me if it's fixing the issue for you?

[jcorporation]

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]

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]

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]

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]

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]

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]

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]

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!