Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: oom killer back active after update...

  1. #11
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,285
    Blog Entries
    2

    Default Re: oom killer back active after update...

    If your vms don't have to be accessed 24/7/365, maybe find a time you can poweroff some vms?
    Also, inspect your settings for minimum reserved RAM, ballooning so you understand when that might happen.
    Consider that unless you're running some pretty fast RAID, pushing all that data into swap could make your machine run dog-slow, almost looking like the system is frozen.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  2. #12
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,054

    Default Re: oom killer back active after update...

    Quote Originally Posted by ceinma View Post
    I'm avoiding to grow the RAM since this is a VM sharing with others VMs
    If the other VMs aren't running databases, you may well have to accept increasing the RAM usage of the VM running the database application …
    • And, possibly, increase the physical RAM on the machine …

  3. #13

    Default Re: oom killer back active after update...

    Quote Originally Posted by ceinma View Post
    I don't mentioned before, but I also have this settings for a long time :

    Code:
    vm.vfs_cache_pressure = 10
    vm.dirty_background_ratio = 1
    vm.dirty_expire_centisecs = 60000
    vm.dirty_ratio = 1
    
    
    vm.swappiness = 0
    Now I changed the swappiness from 0 to 5 , let's see if change any behave of this **** OOM .

    vm.swappiness = 0 means that swap is disabled.

    https://linuxhint.com/understanding_vm_swappiness/

    Changing the value directly influences the performance of the Linux system. These values are defined:

    * 0: swap is disable
    * 1: minimum amount of swapping without disabling it entirely
    * 10: recommended value to improve performance when sufficient memory exists in a system
    * 100: aggressive swapping

    The value of 60 is a compromise that works well for modern desktop systems. A smaller value is a recommended option for a server system, instead. As the Red Hat Performance Tuning manual points out [8], a smaller swappiness value is recommended for database workloads. For example, for Oracle databases, Red Hat recommends a swappiness value of 10. In contrast, for MariaDB databases, it is recommended to set swappiness to a value of 1 [9].
    https://docs.cloudera.com/cloudera-m...parameter.html

    Cloudera recommends that you set vm.swappiness to a value between 1 and 10, preferably 1, for minimum swapping on systems where the RHEL kernel is 2.6.32-642.el6 or higher.
    RTFM!

    To get more memory you may use zram/zswap/zcache.

  4. #14
    Join Date
    Apr 2021
    Location
    Munich
    Posts
    38

    Default Re: oom killer back active after update...

    Quote Originally Posted by ceinma View Post
    ...
    I will add more 4GB to my swap and see what happen, however, I think will change nothing...

    I'm avoiding to grow the RAM since this is a VM sharing with others VMs , I don't want to get resources unnecessary.
    Even SSD based swap space is so much slower than physical RAM...
    The old school formula (2x RAM space = swap swap space) seems deprecated for me. In my opinion, as soon as swap space will be used often times, more phys memory is mandatory.
    There aren't unnecessary resources existent on unix based systems. RAM will also used to cache/buffer frequently operations. If no cache possibility is existent, the system is getting much more slower. And in the light of CPUs these days... swap space as cache is only in barely situations what you want.

    Some of our servers have 768 GB of RAM and only 32 GB of swap. Just to illustrate the ratios. A 16GB VM will get 8-16GB swap.

    Best regards,

  5. #15
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,285
    Blog Entries
    2

    Default Re: oom killer back active after update...

    Quote Originally Posted by gendjaral View Post
    Even SSD based swap space is so much slower than physical RAM...
    The old school formula (2x RAM space = swap swap space) seems deprecated for me. In my opinion, as soon as swap space will be used often times, more phys memory is mandatory.
    There aren't unnecessary resources existent on unix based systems. RAM will also used to cache/buffer frequently operations. If no cache possibility is existent, the system is getting much more slower. And in the light of CPUs these days... swap space as cache is only in barely situations what you want.

    Some of our servers have 768 GB of RAM and only 32 GB of swap. Just to illustrate the ratios. A 16GB VM will get 8-16GB swap.

    Best regards,
    Slow throughput is primarily because of your SATA or SAS interface.
    I've read that if your swap is on NVME M.2 it's incredibly fast, almost like regular RAM (but don't rely on that. Get real RAM instead, especially because prices will likely be similar).

    And, I wouldn't recommend configuring more than a tiny amount of swap space unless you really are anticipating the possibility of unusually high load... As I've said before, a small amount of RAM is lost to supporting SWAP and the more SWAP you use, the more will be stolen from your regular RAM.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  6. #16

    Default Re: oom killer back active after update...

    Quote Originally Posted by tsu2 View Post
    I've read that if your swap is on NVME M.2 it's incredibly fast, almost like regular RAM (but don't rely on that. Get real RAM instead, especially because prices will likely be similar).
    TSU
    RAM is much faster, especially in IOPS. SSD flash is much cheaper than RAM.
    Optane is in between of them.

  7. #17

    Thumbs down Re: oom killer back active after update...

    Hi !

    I really thanks everyone about all suggestions, however my focus here is why this behave back, what change? is the kernel version?

    I don't want to change my RAM settings, this environment ran in this condition for the last two years without any issues.
    Really don't believe the reason is the OS upgrade and they become to consume more memory and triggered all this.

    Enabling the swap now reduced the killer, giving me more time working, but still happen, yesterday triggered again and kill everything included my sessions (old ssh sessions).

    Not sure, but I think this is a kernel resource right?
    I update the kernel with last minor fix (to 5.3.18-lp152.69-default) and growing the swappiness from 20 , if happen again, I will try to downgrade my kernel to version 4.

  8. #18
    Join Date
    Apr 2021
    Location
    Munich
    Posts
    38

    Default Re: oom killer back active after update...

    As far as I know...
    The oom killer could never be disabled. At no time or kernel release...
    I've never heard that before. And in my opinion, it wouldn't make sense.




    I would bet that the extended memory consumption comes from another place and the dimension of your virtual machine just don't fit anymore.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •