vm.overcommit_memory=1 causes NAS crash under sustained file serving

[Frynes]

# vm.overcommit_memory=1 causes NAS crash under sustained file serving

**Model:** F4-212 (2 GB RAM)
**TOS Version:** 5.1.73-00078

## Summary

TOS ships with `vm.overcommit_memory = 1` in `/etc/sysctl.conf` to support Redis. On a 2 GB device, this causes the NAS to become completely unresponsive during sustained file operations (such as large backups over SMB). SSH, SMB, and the web UI all stop responding — only ping continues to work. A physical reboot is required to recover.

## Root cause

With `vm.overcommit_memory = 1`, the Linux kernel approves every memory allocation request without checking available RAM. During sustained file serving, the kernel's slab cache (dentry and inode cache) grows continuously as file metadata is accessed. Normally the kernel would reclaim this cache under memory pressure, but with overcommit set to 1, the kernel never pushes back on allocations. The OOM killer only fires when physical memory is truly exhausted — by then it's too late, and critical processes are killed, making the NAS unresponsive.

## Measured data

During a backup over SMB (rclone reading files via Samba), with monitoring every 2 minutes:

| Metric | Start | +46 min | Change | Rate |
|--------|-------|---------|--------|------|
| MemAvailable | 1,229 MB | 1,133 MB | -96 MB | ~2 MB/min |
| Slab (total) | 117 MB | 563 MB | +446 MB | ~10 MB/min |
| SReclaimable | 53 MB | 473 MB | +420 MB | ~9 MB/min |

Projected crash time at this rate: ~9-10 hours. Actual crash time in testing: 9 hours. This was reproduced across multiple runs.

## Fix

Changing to `vm.overcommit_memory = 0` (the Linux default) allows the kernel to self-regulate slab cache as designed:

**Before fix (overcommit=1):** Slab grew continuously, never reclaimed. NAS crashed after ~9 hours.

**After fix (overcommit=0):** Slab grew to 613 MB, then the kernel automatically reclaimed it down to 246 MB. MemAvailable recovered. No crash, no intervention needed.

## Suggestion

Either:
1. Change the default to `vm.overcommit_memory = 0` in `/etc/sysctl.conf`, or
2. Configure Redis to handle fork failures gracefully without requiring a system-wide overcommit setting

Redis's `fork()` failures with `overcommit_memory = 0` are harmless — Redis keeps running, it just can't snapshot to disk temporarily. On a NAS, Redis stores throwaway session/cache data. The tradeoff of an occasional Redis snapshot failure is far better than the entire NAS crashing and requiring a physical reboot.

## Additional note

`/etc/sysctl.conf` loads last in the `S02sysctl` boot script:
```
SYSCTL_SOURCES="/etc/sysctl.d/ /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ /lib/sysctl.d/ /etc/sysctl.conf"
```
This means `/etc/sysctl.d/` overrides do not work — `/etc/sysctl.conf` always wins. Users who discover the overcommit issue cannot fix it with a drop-in config file; they must edit `sysctl.conf` directly, which may be overwritten by TOS updates.

[MikeZhang]

Thank you very much for your detailed sharing. The methods you provided are of great help and reference value to other users who encounter similar problems.