Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An OOM kill on a Linux server using ZFS does not, by itself, prove that ZFS consumed all available RAM. Linux may have exhausted memory across the host, inside a cgroup, or within another constrained allocation domain, then selected a process according to its OOM heuristics. ZFS’s Adaptive Replacement Cache (ARC) can contribute to pressure, but you need correlated kernel, process, cgroup, and ARC data before changing its limits.
Preserve the kernel report first, identify the exhausted memory domain, compare process growth with ARC statistics, verify the installed OpenZFS version, and then make one measured change at a time. The procedure below is designed to distinguish an ARC issue from a leaking service, an overly restrictive cgroup, or a genuinely undersized machine.
What a Linux OOM error means on a ZFS host
The Linux kernel invokes its out-of-memory (OOM) killer when memory is exhausted and reclaim cannot free enough memory for an allocation. The kernel documentation describes the situation this way: “It is possible that on a loaded machine memory will be exhausted and the kernel will be unable to reclaim enough memory to continue to operate.” See the Linux memory-management concepts documentation for the kernel’s explanation.
“Out of memory” is a statement about an allocation failure in a particular memory domain, not a diagnosis of the subsystem that used the memory. The domain can be the entire host, a memory cgroup, a cpuset, a NUMA or memory-policy restriction, or another constrained set of resources. Linux then chooses a task using OOM heuristics. The name of the killed task is the victim selected to recover memory; it is not proof that the task caused the pressure.
#1 Best Overall
- Read Before You Buy — No Video Output: These adapters support charging and USB 2.0 data transfer, but cannot transmit video signals. Except for standard USB webcams (which use USB data only), they are not compatible with HDMI/DisplayPort cables, video-capable USB-C hubs, or docking stations with video output.
- Convert USB-A Ports to USB-C: Designed to connect USB-C earphones, cables, flash drives, card readers, and other USB-C accessories to standard USB-A ports. Plug-and-play with no drivers or software required.
- Aluminum Alloy Housing: Built with a sturdy aluminum alloy shell that aids in heat dissipation and protects against daily wear and scratches. Designed to maintain a stable and secure connection.
- Compact & Travel-Friendly: The ultra-compact design allows the adapter to stay plugged into your device without blocking adjacent ports or adding bulk, reducing wear and tear on your original USB ports.
- 12-Month Warranty: Backed by a 12-month manufacturer warranty for peace of mind. Designed to meet strict quality control standards for reliable everyday performance.
On a ZFS server, resident application memory, kernel allocations, filesystem metadata, swap state, and ARC pages can all matter. ARC is therefore a plausible participant, but an OOM line alone cannot establish that ARC was responsible. The first objective is to determine where the failure occurred and what was growing at that time.
Linux’s process-level accounting and OOM information are documented in the kernel’s proc documentation. That documentation explains that the memory available to the OOM heuristic depends on the applicable constrained domain, not necessarily on total physical RAM in the machine.
1. Preserve evidence before changing anything
Logs can disappear after a reboot, a volatile journal configuration can discard the previous boot, and changing ARC or cgroup settings can obscure the original state. Capture the incident first. Use commands appropriate to your distribution and whether systemd-journald is persistent.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors- Save kernel messages for the incident. On a running system, try
journalctl -k --since 'YYYY-MM-DD HH:MM' --until 'YYYY-MM-DD HH:MM'. To inspect the previous boot when the journal persisted it, usejournalctl -k -b -1. On systems without a usable journal,dmesg -Tmay show the current kernel ring buffer. Redirect output to a file and copy it off the host. - Search for the OOM report. Look for lines containing
oom,out of memory,killed process,memory cgroup,constraint,cpuset, ormems_allowed. Keep the surrounding lines, because the allocation context and constrained-node information are often more useful than the single “Killed process” line. - Record the boot and kernel identity. Save
uname -a, the distribution release information, and the exact incident time in UTC. Kernel behavior and cgroup layouts vary by release. - Record current memory state without assuming it equals the incident state. Save
free -h,swapon --show,cat /proc/meminfo, and a process listing such asps -eo pid,ppid,comm,rss,vsz,%mem --sort=-rss | head. These are snapshots taken after the event, so label them as such. - Keep application and service logs. A service may log an allocation failure before the kernel kills a process. That message is useful context, but a user-space message saying “out of memory” is not automatically evidence of a kernel OOM kill.
Do not reboot merely to clear the condition until the relevant logs and state have been saved. If a reboot is unavoidable, preserve the journal and service logs first.
2. Establish which memory domain was exhausted
Read the kernel report as a description of the failed allocation’s scope. A host-wide OOM normally includes global memory statistics and a list of tasks considered for killing. A cgroup OOM often identifies a memory-control-group path, a cgroup charge, or a message that the memory limit was reached. A constrained cpuset or memory policy can produce an OOM even while other RAM remains unused elsewhere in the machine.
Check the host’s total and immediately available memory with free -h and the detailed counters in /proc/meminfo. Compare those values with the OOM timestamp, not just with a later idle snapshot. Check swap with swapon --show; whether swap was enabled, full, or absent helps explain reclaim behavior, but swap status alone does not identify ARC as the cause.
Next determine the cgroup version. On many current distributions, stat -fc %T /sys/fs/cgroup reports a cgroup v2 filesystem; older systems may expose cgroup v1 controller directories. The exact files and service paths depend on the distribution and init system. Use the host’s cgroup documentation and inspect the service’s actual directory rather than copying a path from another release.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRank #2
- 5-in-1 USB-C Hub: Experience comprehensive connectivity featuring a Power Delivery input, two USB-A 2.0 ports, a USB-A 3.0 port, and an HDMI port. (Note: The USB-C power delivery input port is only for connecting an external wall charger to power your laptop and cannot power peripheral devices.)
- 90W Pass-Through Charging: Achieve optimal charging with 90W pass-through power to your laptop, supported by a total input of 100W, with the hub reserving 10W for operational efficiency. (Note: Wall charger not included.)
- Quick Data Transfers: Accelerate your productivity with rapid data transfers using a high-speed 5Gbps USB 3.0 port and two 480Mbps USB 2.0 ports.
- 4K HDMI Display: Enhance your visual experience with a hub capable of delivering 4K resolution at 30Hz in both mirror and extend modes. Please note that this hub is compatible with MacBook (macOS 12 and newer), Windows 10 and 11, ChromeOS, and laptops equipped with DP Alt Mode and Power Delivery. Note: This device is not compatible with Linux.
- What You Get: Anker USB-C Hub (5-in-1, 4K HDMI), welcome guide, 18-month warranty, and our friendly customer service.
For cgroup v2
Within the service’s cgroup, inspect files such as memory.max, memory.current, memory.events, and, where present, memory.swap.max. A rising oom or oom_kill counter in memory.events indicates cgroup-level events. Capture the values and the cgroup path before restarting the service.
For cgroup v1
The v1 memory controller commonly exposes files such as memory.limit_in_bytes, memory.usage_in_bytes, and memory.failcnt, but the interfaces are deprecated on many systems. The kernel’s cgroup v1 memory-controller documentation describes those files and their semantics. Follow your distribution’s guidance when cgroup v2 is enabled instead.
Compare the service limit with the process’s resident set and with the host’s free memory. If the cgroup limit is 2 GiB on a host with 128 GiB of RAM, a process can be killed locally while the host still has substantial unused memory. Conversely, a host-wide OOM report with no cgroup constraint points you toward aggregate consumers rather than only the service’s limit.
3. Correlate process memory with ZFS ARC statistics
ARC statistics must be aligned with the OOM timeline. A single reading taken after the kill cannot show which component grew first. Capture repeated samples during normal load and, if possible, during the workload that reproduces the incident.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Read ARC counters. OpenZFS exposes statistics in
/proc/spl/kstat/zfs/arcstats. Save the file and inspect counters such as the current ARC size and the target maximum (commonly represented by fields includingsize,c, andc_max; field names can vary by release). - Use the release-appropriate reporting utility. Current OpenZFS documentation names
zarcstat. Older installations may providearcstatinstead. Confirm the utility’s options withzarcstat --helporarcstat --helpbecause column names and sampling flags differ by version. - Record process RSS and major consumers. Repeat
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 20, or use your service manager’s status and accounting facilities. A process leak can grow while ARC remains stable; a cache-heavy workload can show a different pattern. - Sample over time. Save timestamped ARC and process readings at a fixed interval while reproducing the workload. Correlate the final samples with the kernel OOM timestamp and the cgroup event counters.
ARC can occupy otherwise idle memory and is designed to give pages back under pressure. Seeing a large ARC is therefore not enough to call it the cause. Stronger evidence is a timeline in which application demand rises, reclaim becomes insufficient, ARC approaches its target, and the OOM report identifies the same memory domain. Even then, treat the result as a pressure interaction rather than assuming every ARC page was unreclaimable.
4. Identify the OpenZFS release and active parameters
ARC defaults changed, so advice written for an older Linux ZFS installation may be wrong on a current host. Record the installed version before interpreting a target value.
- Run
zfs versionwhen the command is available. - Check the loaded module with
modinfo zfs | headand record its version field. - Inspect the active parameter through the distribution’s module-parameter interface, commonly
cat /sys/module/zfs/parameters/zfs_arc_max. Some systems expose a persistent setting in a modprobe configuration file instead; record both the running value and the configured value.
OpenZFS documents zfs_arc_max as having a lower bound of 67,108,864 bytes (64 MiB). A value of zero means that the maximum is derived from installed memory. The documented derived defaults are version-dependent:
Rank #3
- Sleek 7-in-1 USB-C Hub: Features an HDMI port, two USB-A 3.0 ports, and a USB-C data port, each providing 5Gbps transfer speeds. It also includes a USB-C PD input port for charging up to 100W and dual SD and TF card slots, all in a compact design.
- Flawless 4K@60Hz Video with HDMI: Delivers exceptional clarity and smoothness with its 4K@60Hz HDMI port, making it ideal for high-definition presentations and entertainment. (Note: Only the HDMI port supports video projection; the USB-C port is for data transfer only.)
- Double Up on Efficiency: The two USB-A 3.0 ports and a USB-C port support a fast 5Gbps data rate, significantly boosting your transfer speeds and improving productivity.
- Fast and Reliable 85W Charging: Offers high-capacity, speedy charging for laptops up to 85W, so you spend less time tethered to an outlet and more time being productive.
- What You Get: Anker USB-C Hub (7-in-1), welcome guide, 18-month warranty, and our friendly customer service.
| OpenZFS release | Documented default calculation when zfs_arc_max is zero |
How to use the fact |
|---|---|---|
| 2.3.0 and later | The larger of total system memory minus 1 GiB and five-eighths (5/8) of total system memory, on all platforms | Do not assume the older Linux half-memory rule; calculate the target from the current release documentation and installed RAM. |
| Before 2.3.0 on Linux | Half of system memory | Older tuning guides may describe this rule, but it does not describe the current 2.3.0-and-later default. |
These are documented defaults, not recommendations. The useful question is how much headroom your applications, kernel, metadata, and workload require after ARC is accounted for.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The parameter behavior and version history are documented in the OpenZFS module-parameters guide.
5. Decide whether ARC is actually competing with applications
Use the evidence to classify the incident before tuning:
- Likely cgroup-local: the OOM report names a memory cgroup or the service’s event counter increments while host-wide memory remains available. Adjust the service limit, workload, or leak only after confirming the cgroup’s policy.
- Likely process-driven host pressure: one or more processes grow steadily, ARC is not unusually high relative to its target, and the kernel report shows a global OOM. Investigate leaks, concurrency, queues, and per-service limits before reducing ARC.
- Possible ARC competition: applications and kernel reclaim are under pressure, ARC is near its target, and reducing cache headroom appears to coincide with recovery in a controlled reproduction. This still requires workload testing because a smaller cache can reduce read-hit performance.
- Possible physical-capacity shortage: the measured working sets of services and the minimum useful ARC cannot coexist within installed RAM, with no practical software reduction available. A RAM upgrade may then be appropriate, subject to exact server and motherboard compatibility.
Do not apply a generic “ARC should be X percent of RAM” rule. The available evidence does not establish one safe percentage for every database, file server, virtualization host, or container workload.
6. Lower zfs_arc_max carefully when evidence supports it
zfs_arc_max is dynamic, so a running system can be given a lower maximum through its module-parameter mechanism. The exact persistent configuration method differs by distribution; use the OpenZFS documentation and your system’s module-loading procedure. A commonly used runtime interface is the file under /sys/module/zfs/parameters/, but verify that the file is writable and that your distribution does not require a different method.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Choose a measured target. Start from the observed application working set and the free-memory margin needed during peaks. Keep the value at or above the documented 64 MiB lower bound and within the limits of your OpenZFS release.
- Change only the ARC maximum. Apply the new value using the supported module-parameter method. Record the old and new values, timestamp, workload, and operator.
- Do not expect instant reclamation. OpenZFS explicitly states that lowering the limit below the ARC’s current size “will not cause the ARC to shrink without memory pressure to induce shrinking.” A lower target is not the same as an immediate free-memory operation.
- Validate under representative load. Continue sampling
arcstats, process RSS, reclaim activity, latency, and OOM events. Confirm that ARC declines when pressure occurs and that application performance remains acceptable. - Persist only after validation. If the change works, place it in the distribution-supported module configuration and document how to roll it back. A one-time runtime change can disappear at reboot; a persistent change can affect every future workload.
Lowering ARC trades cache capacity for application headroom. It may prevent kills while increasing disk reads or latency. If no measurable application headroom is gained, restore the previous setting and investigate the other consumer instead.
7. Understand zfs_arc_shrinker_limit before touching it
OpenZFS also documents zfs_arc_shrinker_limit, a specialized control over how many pages the ARC shrinker makes available for one allocation attempt. The documented behavior applies to kswapd reclaims; it is not a blanket instruction to keep ARC small.
Rank #4
- Dual Converters, Infinite Potential：Includes 2× USB C male to USB A female adapters and 2× USB A male to USB C female adapters. Perfect for a wide range of uses—tablets with Bluetooth keyboards, expand USB ports on macbook, and more. Two different converters for all your daily needs
- Next-Level 10Gbps & 3A Charging: No more slow 480Mbps, this usb to usb c adapter has a transfer speed of up to 10Gbps, allowing you to do more transferring in less time. This usb adapter fits both USB A and USB C charger, supporting up to 3A fast charging
- Upgraded Exquisite Craftsmanship: With an aluminum alloy housing and metal connector, the usbc to usb adapter is extremely durable and sturdy. Rigorously tested to withstand more than 10,000 times of plugging and unplugging, ensuring long-lasting performance
- Broad Compatible: The usb c to usb adapter widely supports all USB C/ USB A devices like laptops, tablets, cellphones, car chargers, and phone chargers. Such as compatible with MacBook Pro/Air 2023/2022, Thunderbolt 4/3 Devices,Apple MagSafe Watch 9/8/7/SE/Ultra, iPad Pro 2022/2021, Samsung Galaxy S23/S20/S10, and iPhone 17/16/15 Pro. Plug and play
- Please Note: To reach 10Gbps speed, keep the cable under 3.3 ft. For USB A Male to USB C adapters, try flipping the USB C connector. USB C Male to USB A adapters support bidirectional 10Gbps transfer within 3.3 ft
| OpenZFS release | Documented default | Interpretation |
|---|---|---|
| 2.0 through 2.2 | 10,000 | A per-attempt shrinker limit documented by OpenZFS, not a recommended universal tuning value. |
| 2.3 and later | 0 | The default changed; verify the release’s documented meaning before changing it. |
Because this parameter affects reclaim behavior rather than simply setting a cache ceiling, change it only when you understand the version-specific semantics and have measurements showing that the shrinker behavior is involved. Test one parameter at a time so a change in OOM frequency or latency can be attributed correctly.
8. Fix non-ARC causes instead of masking them
Application or service growth
Track the largest processes over time, inspect service queues and caches, and check for a known leak in the application version. A service-level limit can contain a runaway process, but setting an arbitrarily low limit can create cgroup OOM kills without reducing total demand. Choose a limit from measured peak usage plus an operational margin.
Cgroup policy
If the event is local to a cgroup, decide whether the limit is intentional. Raise it only when the host has verified headroom and the service’s workload requires it. Otherwise reduce concurrency, split workloads, or correct the process that is growing. Remember that a cgroup limit and host-wide RAM are separate constraints.
Swap and reclaim conditions
Record whether swap exists and whether it was usable at the incident. Swap can change reclaim timing, but enabling it does not create unlimited capacity and does not prove that ARC caused the OOM. Treat swap configuration as part of the host’s memory policy, not as a substitute for measuring demand.
Insufficient physical RAM
Consider adding RAM only after measuring the combined working sets of applications, kernel needs, and the minimum ARC that delivers acceptable performance. A compatible module depends on the exact server model, memory type, capacity limits, slot population, firmware, and existing DIMMs. Without those specifications, no particular part or capacity can be safely recommended.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.9. Do not confuse OOM policy controls with diagnosis
Kernel controls such as panic_on_oom and overcommit settings change what the kernel does when allocations cannot be satisfied. panic_on_oom can turn an OOM condition into a kernel panic, while overcommit modes change when allocation commitments are accepted. They do not identify ARC as the source, add physical capacity, or repair a leak.
Recommended Free Tools
Change these controls only when you have an explicit recovery policy—for example, a clustered service that prefers a reboot over continuing in a damaged state—and understand the consequences for availability and data protection. Keep diagnostic work focused on the memory domain, allocation timeline, and measured consumers.
Best Value
- 5-in-1 Connectivity: Equipped with a 4K HDMI port, a 5 Gbps USB-C data port, two 5 Gbps USB-A ports, and a USB C 100W PD-IN port. Note: The USB C 100W PD-IN port supports only charging and does not support data transfer devices such as headphones or speakers.
- Powerful Pass-Through Charging: Supports up to 85W pass-through charging so you can power up your laptop while you use the hub. Note: Pass-through charging requires a charger (not included). Note: To achieve full power for iPad, we recommend using a 45W wall charger.
- Transfer Files in Seconds: Move files to and from your laptop at speeds of up to 5 Gbps via the USB-C and USB-A data ports. Note: The USB C 5Gbps Data port does not support video output.
- HD Display: Connect to the HDMI port to stream or mirror content to an external monitor in resolutions of up to 4K@30Hz. Note: The USB-C ports do not support video output.
- What You Get: Anker 332 USB-C Hub (5-in-1), welcome guide, our worry-free 18-month warranty, and friendly customer service.
10. Troubleshooting patterns and corrective actions
The log names a memory cgroup
Capture the cgroup path, its limit, current usage, and event counters. Compare those with the service’s process RSS. If only that cgroup is failing, changing a host-wide ARC limit may not solve the problem. Correct the service policy, workload, or leak, then retest.
The killed process is small, but another process is large
This is consistent with OOM victim selection: the kernel may kill a task that is not the largest consumer because its heuristic score and the applicable domain favor it. Use the complete task list and historical process samples to find the growing consumer; do not blame the named victim solely from the log line.
ARC is large immediately after the kill
A large post-incident ARC does not prove it caused the event. Compare pre-incident samples, the ARC target, process growth, and reclaim messages. If you lower the target, remember that shrinkage requires memory pressure and may not be visible immediately.
There is no kernel OOM report
Check whether the message came from an application, a container runtime, a job scheduler, or a service supervisor. Inspect cgroup event files and service logs, and verify that the journal retained the relevant boot. A user-space allocation failure can occur without the kernel invoking its OOM killer.
The problem returns after every reboot
Reboots erase the evidence and temporarily reset working sets. Before the next reboot, enable persistent kernel logging if appropriate, schedule periodic collection of process and ARC statistics, and record cgroup limits. Reproduce under controlled load so you can compare timelines rather than relying on a single post-reboot snapshot.
Choosing among ARC tuning, service limits, and more RAM
Use the following decision axes rather than a one-size-fits-all recipe:
| Remedy | Evidence that supports it | Effect on application headroom | Effect on ZFS performance | Operational characteristics |
|---|---|---|---|---|
Lower zfs_arc_max |
ARC is competing with measured application demand in the same memory domain. | Can increase headroom after pressure causes ARC to reclaim. | May reduce cache hit rate and increase storage I/O or latency. | Dynamic parameter; lowering below current size does not force immediate shrink. Persist only after testing. |
| Adjust an application or cgroup limit | The OOM is local to a cgroup or a service’s measured peak exceeds its policy. | Can contain growth or provide needed working space, depending on whether the limit is raised or lowered. | Usually no direct ARC change, but total pressure may change. | Depends on cgroup version and service manager; verify event counters and paths. |
| Add physical RAM | Measured working sets cannot coexist with acceptable ARC and kernel margins. | Raises capacity for all domains. | Can allow a larger effective cache, but workload benefits still need measurement. | Requires exact hardware compatibility, downtime planning, firmware considerations, and budget. |
Make one change, observe the same workload, and keep a rollback path. If a change alters OOM frequency but causes unacceptable application latency, it is not a complete fix.
A repeatable operating checklist
- Preserve kernel, service, and cgroup evidence before rebooting.
- Determine whether the OOM was host-wide or constrained to a cgroup, cpuset, memory policy, or other domain.
- Compare the selected victim with the full process list; victim identity is not causal proof.
- Record host memory, swap, process RSS, and ARC statistics on the same timeline.
- Identify the exact OpenZFS release and active
zfs_arc_maxand shrinker parameters. - Use the release-appropriate ARC default rules; do not apply pre-2.3 Linux guidance to OpenZFS 2.3 or later.
- If ARC competition is demonstrated, lower its maximum cautiously and allow pressure to induce shrinking.
- Test service limits, leak fixes, or workload changes when evidence points away from ARC.
- Evaluate a RAM upgrade only after measuring capacity requirements and confirming hardware compatibility.
- Document every change, its timestamp, observed effect, and rollback procedure.
The reliable answer to “Why is Linux killing processes on my ZFS server?” comes from this correlation: the kernel’s memory domain and allocation context, the cgroup and process evidence, and ARC behavior over time. Once those agree, tuning becomes a controlled engineering decision instead of a guess based on the size of the cache or the name of the killed process.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
