sweaty_decision_meme.jpg

- Debugging some application locally (with debugger)
- 20-30 manual step-ins, tracking those values VERY closely
- debugger becomes a little sluggish
- move mouse to select a line to jump to
- cursor is lagging: all jumpy and everything
- CTRL+ALT+F1
- everything freezes.

sooo...either reboot the laptop and lose all the work, or wait for OOMK to kick in, which could be hours, depending on the level of memory starvation.

Don't you roughly remember the conditions of the step-ins so that you can set a breakpoint roughly where you last were?

@kamen I do remember where these breakpoints are to be. However, I don't really remember all the changes I had to make in the library at runtime (using the debugger's evaluation feature) to get to those spots :)

Why is this kind of a freeze even possible in a modern system

@electrineer because the application tried to load and parse 200MB of data. Loading it is easy - just additional 200MB of ram. Parsing it, on the other hand, exploded the payload to ~5GB.

I also have 2 actively used servers spun up on my laptop (my automation at a sort of UAT stage - still waiting for a dedicated env to be created), one of which got a request requiring additional ~8G of RAM. 2 IDEs, 3 chrome windows with multiple tabs, a windows VM, and that same 200MB file opened in xed (which apparently is a horrible notepad alternative when it comes to large-ish files).

All added up to ~35GB RAM, when I only had 32 on my lappy.

kswapd + OOMK kind of saved the day. Took ~1 hour, but they made it. hung_task.c also logged that page_fault calls were hitting the 120sec timeout, which is kind of impressive (120sec to retrieve a memory page from RAM!!!) and confirms the agony the OS had to survive.

Haven't spoiled my 167d uptime! I call that an absolute win!

@netikras but why does it have to take an hour? Wouldn't it be nice if only the growing process was starved and the rest of the system was kept always responsive.

@electrineer yes, it would be. But kernel and user spaces are sharing the same memory pool :)

It would not take an hour if either of the processes could be easily swapped out. Since both the server and the debugged process were actively using those pages, they were locked for swaping out.

Reserving memory for separate processes would be inefficient :) and hardly of any use. There's a reason most of the systems overcommit memory heavily ;)

He's using React

@truelion07 nope, openJDK15

@netikras
You're a mad man to do this on a local or even laptop ='D
Congrats for the lucky finale.

@scor I've been that madman for months now :)

I need folks to test that thing. Especially the natural language processor. And there's no other as flexible place to run that thing on than a work laptop :)

does ctrl+alt+backspace not do anything anymore?

@Parzi killing X would kind of beat the point of trying to save my session :/

@netikras true. my bad.