System pressed for memory during file copy, causing oom-killer to be invoked #5626
Comments
|
If you haven't done this already, as a work around I'd recommend trying the xen tunings described in the FAQ. Both xen and zfs put an above average amount of stress on the Linux VM. The good news is that we've done a huge amount of work to improve things on the zfs side, those improvements will first appear in the 0.7.0 major release. Pre-releases are available which contain the needed improvements, and if you're in a position where you can test the pre-release and we'd love independent confirmation. Thanks. |
|
Looking at your System Info I see you're running kernel 4.4.0-59 on Ubuntu 16.04 which has a confirmed OOM-Killer bug see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1655842 Looks like there are 3 options ...
If you do go with option 2 then put the 4 files in the same directory and type sudo dpkg -i *.deb then sudo update-grub2 reboot and you're good to go. This is the route I've taken as the OOM Killer was also nuking all my KVM machines! UPDATE: This kernel is now available in the proposed repository (https://wiki.ubuntu.com/Testing/EnableProposed). FYI I've been running this now for 2 days on a 8Gb system with 4Tb RAIDZ1 ZFS Pool and a few KVM and LXD virtual machines running and all the OOM problems are gone. |
|
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
System information
Describe the problem you're observing
To test ZFS, I copy some files back and forth between ZFS and normal storage. Specifically, I use qemu-img to convert vmdk files to raw images, and then copy these raw images into zvol.
This works fine, but tonight I noticed that the OOM killer came to pay a visit. Apparently the system (8GB RAM) is so pressed for memory, that it killed the qemu-img process, and then went ahead and killed the much smaller snapd demon (had the snapd demon been just a bit smaller, it'd have killed the accounts-daemon).
I am aware that ZFS loves RAM, and that people use it with 100+GB. That's not the point of this issue though. There are no VMs running, so those 8 GB are for the restore, and ZFS to use. I'm surprised that ZFS basically runs the system against a wall, and that apparently running anything else on a ZFS machine is subject to getting oom-killed at any time.
Describe how to reproduce the problem
Installed ZFS on Ubuntu 16.04.
Creating the pool:
Adding L2ARC:
I don't recall any other specific configuration being done (other than this being on a xen dom0, which however does not have any VMs running). The system does not seem to be pressed for memory, this is during the copy process:
Include any warning/errors/backtraces from the system logs
This only happens once, and the remaining vmdk files were copied properly (without the oom-killer). Repeating the process also caused the vmdk in question to be copied properly.
This is preceeded by a few hung tasks log messages, which happened hours before that, but didn't seem too related, hence just for completeness sake:
The text was updated successfully, but these errors were encountered: