Yes, the Out of Memory (OOM) killer will do that when enabled, everytime.
System logs from around the time of the behaviour will confirm:
Example:
kuk-qx kernel: [15709] 0 15709 5347 110 1 0 0 _mprosrv
kuk-qx kernel: [15720] 0 15720 2361279 328780 1 0 0 _mprosrv
kuk-qx kernel: Out of memory: Kill process 10126 (_progres) score 134 or sacrifice child
kuk-qx kernel: Killed process 10126, UID 500, (_progres) total-vm:5330656kB, anon-rss:4292kB, file-rss:1628608kB
kuk-qx kernel: Out of memory: Kill process 21066 (_progres) score 117 or sacrifice child
kuk-qx kernel: Killed process 21066, UID 500, (_progres) total-vm:5344688kB, anon-rss:18108kB, file-rss:1401832kB
kuk-qx kernel: Out of memory: Kill process 7543 (_progres) score 116 or sacrifice child
kuk-qx kernel: Killed process 7543, UID 500, (_progres) total-vm:5349984kB, anon-rss:9360kB, file-rss:1395376kB
kuk-qx kernel: Out of memory: Kill process 25421 (_progres) score 110 or sacrifice child
kuk-qx kernel: Killed process 25421, UID 0, (_progres) total-vm:5351912kB, anon-rss:2400kB, file-rss:1692496kB
kuk-qx kernel: Out of memory: Kill process 25427 (_progres) score 109 or sacrifice child
kuk-qx kernel: Killed process 25427, UID 0, (_progres) total-vm:5352364kB, anon-rss:8256kB, file-rss:1685168kB
kuk-qx kernel: Out of memory: Kill process 21973 (_progres) score 102 or sacrifice child
kuk-qx kernel: Killed process 21973, UID 500, (_progres) total-vm:5350628kB, anon-rss:9476kB, file-rss:1235044kB
kuk-qx kernel: Out of memory: Kill process 24746 (_progres) score 100 or sacrifice child
kuk-qx kernel: Killed process 24746, UID 500, (_progres) total-vm:5358904kB, anon-rss:17640kB, file-rss:1201736kB
kuk-qx kernel: Out of memory: Kill process 15720 (_mprosrv) score 90 or sacrifice child
kuk-qx kernel: Killed process 15720, UID 0, (_mprosrv) total-vm:9445116kB, anon-rss:544kB, file-rss:1455012kB
kuk-qx kernel: Out of memory: Kill process 95121 (_mproapsv) score 286 or sacrifice child
kuk-qx Kernel: Killed process 95121 (_mproapsv) total-vm:92897448kB, anon-rss:65891048kB, file-rss:0kB, shmem-rss:8371980kB
The process which is chosen to die by the Linux OOM Killer, is based on a heuristics weighting and has nothing to do with the current ownership of executables. It has to do with how much memory that process is requesting at the time and since the Linux kernel has memory overcommit behaviour (as default), allowing processes to allocate more memory than is currently free and available on the system at the time, a database can be started with more memory than was currently available at the time.
As soon as the Linux Kernel runs out of memory, once old page frames have been reclaimed, the OOM killer kicks in and starts 'kill or sacrifice child' to keep the OS itself operational and prevent kernel panic.
The Linux OOM killer applies to any process running on the system. In the OpenEdge context, this could for example apply to running and IDXBUILD with -TF 100% or in reality a percentage of available memory higher than that available due to the fact Linux allows processes to start by over committing memory
Further research into the select_bad_process() OOM killer logic can be found in the OS documentation.
|
