A
A
avion2020-12-06 11:27:03
linux
avion, 2020-12-06 11:27:03

OOM killer work?

What is the difference between xmalloc cannot allocate n bytes and Killed(pid) error?

And tested with the following script:

#!/bin/bash

> report.log

arr=()
cnt=0

while true; do
    let "cnt++"
    arr+=({1..10})
    (( ($cnt % 100000) == 0 )) && echo "${#arr[*]}" >> report.log
done

If I get an overflow error and killing the process oom killer: Killed (pid)
Then looking at the log (dmesg | egrep 'mem\.bash' | tail -n -2):
[74408.036383] Out of memory: Killed process 6526 (mem.bash) total-vm:1175296kB, anon-rss:657360kB, file-rss:0kB, shmem-rss:0kB, UID:1000
[74408.728476] oom_reaper: reaped process 6526 (mem.bash), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

But if xmalloc fails, then there is no record of oom killer running.
Why is oom killer not called? At some iteration of the loop, an allocation error occurs, it turns out that the oom killer will only work if the process was able to allocate memory and there is no more free memory?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
Saboteur, 2020-12-06
@saboteur_kiev

IMHO
, well, xmalloc is specifically your process that tried to request more memory and it didn’t work out,
and OOM killer is when there is not enough memory in the system (not necessarily your process, the system is multitasking, at that very moment other processes could also request memory, or corny swap did not have time to respond), and the OS starts the OOM killer process, which chooses which process to kill. There, the algorithm is quite simple - priority for killing is given to user processes that consume a lot of memory. The algorithm also tries to kill as few processes as possible. In your case, apparently, your bash process consumed the most, which is why it turned out to be the first candidate.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question