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 →Linux’s “TCP: out of memory” warning does not, by itself, prove that the host has run out of physical RAM. It can indicate pressure on TCP’s host-wide memory accounting, while a connection spike, large socket buffers, orphaned connections, or a container memory limit may be behind it. Check the live net.ipv4.tcp_mem values and the workload before raising the limit; there is no universal triplet that is safe for every host.
What tcp_mem controls
net.ipv4.tcp_mem is a host-wide set of three thresholds for memory used by TCP sockets. The values are counts of system memory pages, not bytes or kilobytes. Linux calculates defaults at boot based on available memory, so the values can differ between machines.
| Value | Meaning |
|---|---|
min |
Below this threshold, TCP is not constrained by this setting’s memory appetite. |
pressure |
Above this threshold, TCP moderates memory consumption and enters memory-pressure mode. It leaves that mode after usage falls below min. |
max |
The maximum number of pages allowed for queueing by all TCP sockets. |
The Linux kernel documentation describes these thresholds in pages; the Linux tcp(7) manual calls the vector [low, pressure, high] and likewise describes the high value as the global TCP allocation limit. The exact live values depend on the kernel and host.
Check the live values and the actual constraint
Read the TCP thresholds in context
-
Run
sysctl net.ipv4.tcp_memto record the current triplet.Free tools Windows power users keep installed
One-click scans. No signup required.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Run
getconf PAGESIZEto find the system page size. To express a threshold in bytes, multiply its page count by this page size. The result is a threshold conversion, not a measurement of current TCP memory use. -
Capture host memory availability and any cgroup or container memory limits. A process or container can face a tighter memory budget than the physical host suggests.
Inspect connections and kernel logs
Compare the warning’s timestamp with socket counts and states, connection spikes, retransmits, listener backlog behavior, and application restarts or errors. Look for unusually high concurrency, connections that remain open longer than expected, and orphaned sockets. A host can encounter TCP pressure with physical RAM still available if TCP usage is high or the workload is constrained by a memory cgroup.
These observations help distinguish a limit reached during normal peak load from a connection leak, abrupt traffic surge, or memory-budget mismatch. A warning alone does not identify which condition applies.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Separate aggregate TCP pressure from other limits
| Control or condition | Scope | Why it matters |
|---|---|---|
tcp_mem |
Aggregate TCP memory thresholds for the host | Governs TCP’s overall memory accounting rather than a single socket’s requested buffer. |
tcp_rmem and tcp_wmem |
Receive and send buffers per socket | Buffer sizing and TCP autotuning can increase aggregate memory use across many sockets. |
net.core.rmem_max and net.core.wmem_max |
Limits on socket-buffer requests | These constrain requests, but they do not replace the host-wide TCP thresholds. |
tcp_max_syn_backlog |
SYN queue for an individual listener | This is a per-listener backlog limit, not the same accounting mechanism as tcp_mem. The current Linux kernel documentation estimates that one SYN_RECV request socket consumes about 304 bytes. |
tcp_max_orphans |
Limit for orphaned connections | The Linux tcp(7) manual says an orphan can consume up to approximately 64 kB of unswappable memory. If the orphan limit is exceeded, orphaned connections are reset and a warning is printed. |
| Cgroup or container memory limit | Memory available to a constrained workload | A workload may hit its own memory ceiling even when the host still has available RAM. |
Why SYN backlog and orphan warnings need different responses
A high SYN backlog concerns pending connection requests at a listener; it should be investigated as a listener and connection-arrival problem, not automatically treated as evidence that the global tcp_mem ceiling is too low. Repeated orphan growth points to connections whose lifecycle or workload deserves attention. Because an orphan can consume unswappable memory, raising a limit without addressing sustained orphan growth can increase memory risk.
Decide whether changing tcp_mem is justified
Do not copy a triplet from another machine or apply a generic “increase” value. The defaults are derived from available memory, and a safe override depends on the host’s memory budget, expected concurrent connections, buffer behavior, and any cgroup limits. There is no authoritative universal tcp_mem number or benchmark that establishes one correct setting for all workloads.
- Fix the cause first if evidence points to a connection leak, abnormal connection churn, growing orphan count, or oversized buffers.
- Evaluate buffer settings together if many connections or TCP buffer autotuning appear to drive aggregate use. Changing
tcp_memalone may not address the source of that demand. - Consider an override only with a memory budget that accounts for TCP alongside applications and other kernel memory use, and that preserves appropriate headroom under peak load.
Make and validate a reversible change
-
Save the current
net.ipv4.tcp_memvalue and record the related buffer settings and memory limits before changing anything. -
Choose one control to change at a time. Base any
tcp_memoverride on the host’s workload and memory budget rather than another system’s page counts.Recommended: Crashes or Glitches? A Free Driver Scan Usually Finds the Culprit →Recommended: Fix Windows Errors and Clear Junk Files in Minutes - Free Scan →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.Best Value
-
Apply the change through the platform’s normal sysctl configuration process so it matches local operational practice. Keep a clear rollback value.
-
Observe TCP memory, socket counts and states, host and cgroup memory, latency, drops, retransmits, and application errors during representative load. Compare the result with the same signals recorded before the change.
-
Roll back if memory headroom becomes unsafe or the change does not improve the relevant symptoms; investigate the workload or another limiting control instead.
Why bypass_prot_mem is not a general workaround
The Linux network sysctl documentation defines bypass_prot_mem as skipping socket-buffer charging to global per-protocol accounting, including net.ipv4.tcp_mem; its documented default is 0 (off). Skipping that accounting changes what the global counter reflects. It does not reduce the underlying memory demand, so it is appropriate only when there is a specific, documented kernel or application reason to use it—not as a blanket response to a TCP memory warning.
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.
