earlyoom: earlyoom will terminate itself

mem avail:    21 of   950 MiB ( 2.27%), swap free:   81 of 1023 MiB ( 7.95%)
low memory! at or below SIGTERM limits: mem 10.00%, swap 15.00%
sending SIGTERM to process 397 uid 61876 "earlyoom": badness 0, VmRSS 1 MiB

Maybe this should be prevented by default? (Apologies if it is already, running earlyoom 1.6-1 from archlinux.)

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 19 (12 by maintainers)

Commits related to this issue

Most upvoted comments

One could check whether the memory situation is still dire after picking a process.

Yes, that’s what I was thinking about as well. Because, if we look at the stats, kill_largest_process takes about 400x longer than parse_meminfo (check how free memory is doing). That 400x number is roughly the number of processes you have running, so it will be higher with lots of processes, because earlyoom has to look at each of them.

$ make bench
go test -run=NONE -bench=.
goos: linux
goarch: amd64
pkg: github.com/rfjakob/earlyoom
Benchmark_parse_meminfo-4          	  199910	      6511 ns/op
Benchmark_kill_largest_process-4   	     534	   2468413 ns/op
Benchmark_get_oom_score-4          	  195270	      5567 ns/op
Benchmark_get_oom_score_adj-4      	  228506	      5071 ns/op
Benchmark_get_vm_rss_kib-4         	  211107	      5487 ns/op
Benchmark_get_comm-4               	  162548	      6702 ns/op
PASS
ok  	github.com/rfjakob/earlyoom	7.660s

I think the kernel oom killer is race-free because it freezes all processes (or freezes all allocations?)

what if there’s a memory leak in earlyoom?

Set in earlyoom.service, for example:

TasksMax=10
MemoryMax=50M
MemorySwapMax=0

https://github.com/rfjakob/earlyoom/pull/207