[Discussion] Oom Killer fine tuning (overcommit_ratio value)

Question

92

[Discussion] Oom Killer fine tuning (overcommit_ratio value)

asked 2014-12-25 14:23:02 +0200

leszek
10282 ●101 ●145 ●150

As for Update 10 I saw many unhappy with the memory killer kicking in to much and kill applications. As I also had this on christmas eve and it buged me I messed a little around with the settings. Just like on the old vm.swappiness thread which brought many interesting suggestions. I also like to discuss the fine tuning of the OOMKiller behavior.

As I see it currently the main setting for the OOMKiller can be set in /proc/sys/vm/overcommit_ratio. It is default to the value 50.

What does this mean ? This value is a percentage value that is used in the following equation. The result of that equation is the maximum for every app to take before OOMKiller starts kicking in and killing applications.

(50% * RAM Size) + SWAP Space By default on update 10 this value should be around 1 GB if I am not mistaken. (811 MB * 0.5 + 613 MB)

By raising the value more general memory (swap + ram) can be used until OOM Killer kicks in.

I raised it to even 90% but I am not sure if this is a good idea as I only opened up 4 Browser Tabs (Sailfish-Browser) + media player + calculator + Warehouse + Terminal + Jolla Store + MeeCast + Settings

I am not sure if any app gets killed when I now get a call or if it will lag. At least I still feel the system for my needs is still fast enough. Though on occasion when for example opening up meecast (which is the longest running app and not so often used) I can see how it is pulling it from swap as it lags slightly to show up. But this is very subtle. (You really need to focus to even see this)

A more sane value to first test with I guess would be 75 % or even 60 %.

To do this open up the terminal and devel-su You can change the value directly (for testing purposes) by entering

echo 75 > /proc/sys/vm/overcommit_ratio

Replace the 75 with the value you want to test.

I hope this thread can start a good discussion about a healthy new default value so that frequent OOMKillings can be stopped in a quick fix for update 10 or update 11.

edit retag flag offensive close delete

Comments

'75' works reasonably well for me, no glitches/killed applications so far.

rod ( 2014-12-25 20:30:18 +0200 )edit

Thanks for this discussion. The overly agressive app killing is very troublesome for me. Testing 75 now.

salyavin ( 2014-12-25 23:57:06 +0200 )edit

14

I suggest having an option in sailfish utilities or control panel where you can adjust a slider bar to control the aggressiveness of OOM behaviour. or some options like

a setting that allows user to choose behaviour where if you are running low on RAM, the OS will issue an error / warning that you are low on RAM and you should terminate other apps. it will then refuse to launch the app you wanted to.
automatic app termination
a slider bar where you control how aggressive OOM is (left = least aggressive, right = most aggressive)

makes sense?

droll ( 2014-12-26 09:03:46 +0200 )edit

Testing with 75 and first tests look very promising. Thank you for sharing this.

rooster13 ( 2014-12-29 10:20:21 +0200 )edit

After last sys update (1.1.1.27) I have problem with TeamViewer app when it almost establish connection, app just crashed every time.. Don't know what to do, and it worked perfectly before sys update... Tried your tip and changed to 70 and 90, but app continue crashing... Is it necessary to reboot/shutdown/refresh homescreen after changing ?

Schturman ( 2015-01-06 11:55:56 +0200 )edit

'75' works reasonably well for me, no glitches/killed applications so far.
rod ( 2014-12-25 20:30:18 +0200 )edit
Thanks for this discussion. The overly agressive app killing is very troublesome for me. Testing 75 now.
salyavin ( 2014-12-25 23:57:06 +0200 )edit
I suggest having an option in sailfish utilities or control panel where you can adjust a slider bar to control the aggressiveness of OOM behaviour. or some options like
a setting that allows user to choose behaviour where if you are running low on RAM, the OS will issue an error / warning that you are low on RAM and you should terminate other apps. it will then refuse to launch the app you wanted to.
automatic app termination
a slider bar where you control how aggressive OOM is (left = least aggressive, right = most aggressive)
makes sense?
droll ( 2014-12-26 09:03:46 +0200 )edit
Testing with 75 and first tests look very promising. Thank you for sharing this.
rooster13 ( 2014-12-29 10:20:21 +0200 )edit
After last sys update (1.1.1.27) I have problem with TeamViewer app when it almost establish connection, app just crashed every time.. Don't know what to do, and it worked perfectly before sys update... Tried your tip and changed to 70 and 90, but app continue crashing... Is it necessary to reboot/shutdown/refresh homescreen after changing ?
Schturman ( 2015-01-06 11:55:56 +0200 )edit

Answer 1

4

answered 2016-01-04 01:30:40 +0200

Kenno
41 ●2 ●2

situation, 2016, os ver 2.0.0.10, apps get closed on multitask screen ( stay grayed to be reopened upon tap ) both natives and android. It happens even when only browser and settings are open..... Jolla, this makes this phone unusable! Afak, this problem is known over a year now... I cannot copy my friends new phone number from linkedin to contact app by switching between apps to read - write manually without either app go "dead".?????? is this normal? Going for restart and disabling android support, hoping to have that good old jolla behaviour back ( live apps) that i had before. Fix this! Now!

edit flag offensive delete publish link

Comments

May be not OOM killer make problem? How free space on internal storage? I have multi times same problem when free space on btrfs was less than 1.5G.

hyper_sonic ( 2016-01-04 05:28:59 +0200 )edit

1

8.3G free...

Kenno ( 2016-01-04 07:27:05 +0200 )edit

Answer 2

0

answered 2015-03-05 04:18:43 +0200

droll
10097 ●163 ●243 ●257

updated 2015-03-05 04:19:23 +0200

Btw i reinstated those settings shared above for oom min free and overcommit in os 1.1.2.16 and the phone is jerking / jittering significantly less. in is smooth 95% of the time as compared to almost for sure it will jitter when i do very heavy web browsing. using sysmon from openrepos, i can see the that swap usage has significantly dropped, and i am guessing this is why.wh (most likely from the overcommit setting. the stock setting in 1.1.2.16 is 50%). i could be wrong with this analysis so feel free to correct me.

in the past the phone would completely stop becoming responsive for long periods (typically 10s or more). also with sysmon i can see the reason for the unresponsiveness is a huge spike in swap utilization.

edit flag offensive delete publish link

Comments

1

Overcommit_ratio does not have effect in anyway because /proc/sys/vm/overcommit_memory has been set 1 which mean every malloc() will succeed.

I would recommend you to try with the default settings of the 1.1.2.16 release.. :)

tigeli ( 2015-03-05 11:11:25 +0200 )edit

i did try with the default settings of 1.1.2.16, and the experience was not good. I've been running the new settings of 1536,2048,4096,6120,18360,25600 for min free since 9 hours ago and I can report the phone definitely feels much snappier to me. much less instances of jitter.

droll ( 2015-03-05 11:29:28 +0200 )edit

@droll Well only thing you pretty much do is that lowmemorykiller starts killing processes later than the default values do, and you have one extra value (25600) which should not be there.

Defaults: 4096,6144,8192,12288,20000

Your values: 1536,2048,4096,6120,18360,25600

Those values will be compared to oom_score_adj-values 0,58,117,529,1000. Meaning that when the processes having oom_score_adj-value between 0-58 will get killed when there are less than 16MB (default) / 6MB (your) memory available.

The same goes on :

oom_score_adj : default / yours

0-57: 16MB / 6MB

58-116: 24MB / 8MB

117-528: 32MB / 16MB

529-999: 48MB / 24MB

1000: 78MB / 72MB

Then there is extra_free_kbytes which is set to have 16384, so kernel will always try to have 16MB of free ram available.

Basicly your values let the system use more swap, nothing else.. as with 1.1.2.16 the swap is properly taken in account with the lowmemorykiller (only 70% of swap is accountable). I can't think any real reason why would allowing system to swap more to make the system any snappier.

tigeli ( 2015-03-05 17:41:03 +0200 )edit

[Discussion] Oom Killer fine tuning (overcommit_ratio value)

Comments

2 Answers

Comments

Comments

Question tools

Stats

Related questions

[Discussion] Oom Killer fine tuning (overcommit_ratio value)

Comments

2 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions