Hacker News new | ask | show | jobs
by tonyarkles 2497 days ago
There are discussions happening on LKML right now about how to solve this. I don’t have a link handy, but saw them either here or on LWN recently.

I used to have that problem too, but it went away when I stopped using JetBrains products :). Not for any reason other than the contract I was working on ended.
1 comments
minimaul 2497 days ago
Then I shall live in hope that it will be fixed :)

And I didn't even have a JetBrains product in the loop, it was a mix of virtualbox and VS code, along with browser, mail client, etc.

link
tonyarkles 2497 days ago
To elaborate a bit based on my understanding of the issue: VirtualBox seems like a great program to tickle the issue.

During a memory pressure scenario, the kernel starts looking around for things that it can get out of RAM to free up space. If swap is enabled and not saturated, paging out some data to disk is a likely option. Reducing disk cache size works too. But... when the usual candidates run out, things have to get more clever. Things like shared libraries can get paged out! If one of those pages is requested, it can be reloaded from disk. Or, in the VirtualBox case, the mmap'd disk image can be removed mostly from RAM and have those pages loaded from disk as needed. Performance sucks terribly, but it keeps trucking on.

The wrinkle in all of this is SSDs. The out-of-memory (OOM) killer heuristically watches the system and kills off processes that cause memory pressure problems. These heuristics, however, are expecting these page-in and page-out operations to be slow (as they were on HDDs). On newer SSDs, the disks are too fast to trip the OOM killer into action! This is why, when this problem manifests, your disk activity light goes on solid, even if you don't have swap enabled. The kernel is sitting there trying every trick in the book, and the OOM killer doesn't see what's happening. Every individual page fault is handled quickly, there's just waaaaaay too many of them.

link
bscphil 2496 days ago
Yep, this is an accurate description according to my understanding of the issue too.

The lesson I've recently learned is that, for now, swap is necessary on Linux machines with SSDs. I've enabled zswap and added a 4 GB swap file to my machine with 16 GB of RAM, and the problem hasn't reoccurred for me since then. Supposedly, the memory pressure measure in the kernel gets a more accurate reading when swap is enabled, but I don't know for sure that that's true. At the very least, you can page out the memory you're using the least instead of file-backed pages, which is what happens in memory pressure situations on SSDs (as opposed to OOM killing).

link
bo1024 2497 days ago
Wow, that's a really cool explanation. Although, I've had an SSD in my desktop for 8 years now, it's a bit sad to hear.
link
Abishek_Muthian 2497 days ago
I saw it as more of a Java problem on Linux than a Jetbrains one with Android Studio.

When Android Studio is run with large code base on emulator, memory issues were frequent in Linux with halting issues. SO has several such cases.

No such issues with macOS, even with mutiple Jetbrains IDEs in parallel(Same memory config).

I wonder how Android Studio is doing on ChromeOS, considering many of those are low end machines. I'm sure they had to optimize it, but I assume the issue would persist till the Linux kernel itself is fixed.

link