Enormous KBFS memory usage when not doing anything (Arch Linux)

[quantum-dan]

So right now I'm not uploading or downloading anything (and the Keybase app agrees, it says "Done" with regards to files) and my memory usage looks like this:

Log ID: bb31cd3b22499f77350fce1c

That's a fraction of my memory, but it's enough to cause noticeable slowdown here and there.

Yesterday I started making a Veracrypt container but changed my mind and cancelled it, so that's not being uploaded. I just finished making a backup to my private directory using Borg Backup a couple of hours ago, so I could understand the memory usage back then, but it's still high a few hours later.

[strib]

2 things:

• I don't know much about Arch, but you're sure that's reporting resident memory usage, and not just virtual memory usage, right? Our programming language Go has an issue releasing the latter I think, but it wouldn't actually affect available memory.
• I think I just found and fixed a memory leak, the PR is still in review: prefetcher: fix memory leak and possible hang when skipping fetch #1956. I see a bunch of prefetcher stuff in your logs so it could very much be related.

[quantum-dan]

• I'm not entirely certain which, but my system is definitely short on available memory as a result. This is the first time in years that it's actually started using swap storage.
• That could explain things. Thanks.

[da-code-a]

This issue just appeared in the latest update on an Ubuntu 18.04 system as well. Computer slowed down to a halt, couldn't even send a Slack message until I killed the main kbfsfuse process. See screenshot:

[strib]

I'm very confused, there should only be one kbfsfuse process running at a time. Where are the other ones coming from? cc: @heronhaye

Anyway @DonaldKBrown please run keybase log send, and if you're still having the issue while kbfs is running and mounted, please also save the contents of the /keybase/.kbfs_profiles directory.

[heronhaye]

I believe it's the different threads, you can turn off hide userland process threads in F2.

[da-code-a]

@strib : My log id is b3e1deb590f3212f0f10411c. Thank you for looking into this.
@heronhaye : I like to keep them displayed to see if anything is spawning more than it should. It sometimes makes it difficult to find what I'm looking for, but I've gotten used to it 😉

[maxtaco]

Agreed almost certainly the same process, since the memory stats all line up. Also note slack showing the same thing.

[strib]

Ok thanks. @DonaldKBrown are you still having the high memory usage? If so, can you share the contents of /keybase/.kbfs_profiles/ with me? Like cp -r /keybase/.kbfs_profiles/{block,goroutine,heap,mutex} /keybase/private/strib,donaldkbrown. Thanks!

From the log it seems busy prefetching a big file from one of your team folders into your local disk cache, to give you fast access to it if you want it. This is a new feature with this release so it must have a few bugs. It's obviously not supposed to slam your CPU or cause a memory leak, so I'll look into it. But it'd be helpful to get a memory profile so I can tell where the leak is.

[da-code-a]

@strib After killing the main thread, I initially wasn't able to access KBFS through Nautilus; it gave a "Software caused connection abort" error. I opened the Keybase desktop app and selected the "Files" tab, which reconnected me to KBFS. Memory usage appears normal now, I've shared those files with you.

[strib]

Ok thanks. If you see that again, please capture those profile files before you kill it, if possible. Inspecting the code I do see one more possible leak, so I'll fix it soon and we'll go from there...