{"id":1285,"date":"2026-10-03T23:08:43","date_gmt":"2026-10-03T23:08:43","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1285"},"modified":"2026-10-03T23:08:43","modified_gmt":"2026-10-03T23:08:43","slug":"linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/","title":{"rendered":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap"},"content":{"rendered":"<p class=\"wp-block-paragraph\">Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your application, your page cache, and your database. Three sysctls govern this: <code>net.ipv4.tcp_mem<\/code> (the global memory a single protocol may consume), <code>net.ipv4.tcp_wmem<\/code>\/<code>tcp_rmem<\/code> (per-socket send and receive buffer bounds), and the overcommit policy that decides whether the kernel even honours the allocations it promises. Raising buffers without understanding the interaction is one of the most common causes of a VPS that performs well under test and dies under real concurrency.<\/p>\n<h2 class=\"wp-block-heading\">What each knob actually bounds<\/h2>\n<p class=\"wp-block-paragraph\"><code>tcp_rmem<\/code> and <code>tcp_wmem<\/code> take three values each: minimum, default, maximum. The kernel auto-tunes the buffer between min and max based on the connection&rsquo;s bandwidth-delay product, starting at the default. <code>tcp_mem<\/code> takes three pages counts: below the first, no pressure; above the second, the kernel begins pressure-reduction; at the third, it refuses new allocations. Many tuning guides set only the per-socket maximums to huge values and never touch <code>tcp_mem<\/code>, so the global ceiling caps them anyway or memory pressure starts early.<\/p>\n<h2 class=\"wp-block-heading\">Read current values before changing anything<\/h2>\n<pre class=\"wp-block-code\"><code>sysctl net.ipv4.tcp_mem net.ipv4.tcp_rmem net.ipv4.tcp_wmem\nsysctl net.ipv4.tcp_moderate_rcvbuf\ncat \/proc\/net\/sockstat        # current TCP memory use in pages<\/code><\/pre>\n<p class=\"wp-block-paragraph\"><code>\/proc\/net\/sockstat<\/code> line <code>TCP: inuse ... mem N<\/code> is the ground truth for how many pages are currently charged to TCP. Compare N against the first value in <code>tcp_mem<\/code> to see how close to pressure you run in production. Interpreting idle values tells you nothing &mdash; sample under load.<\/p>\n<h2 class=\"wp-block-heading\">Sizing by connection count, not by copy-paste<\/h2>\n<p class=\"wp-block-paragraph\">Worst-case socket memory is roughly <code>max_connections &times; (tcp_rmem_max + tcp_wmem_max)<\/code>. On a 1 GB VPS that number is trivially larger than RAM, which is why the automatic <code>tcp_mem<\/code> ceilings exist &mdash; they stop the kernel from over-allocating. Do not multiply maximums by connection counts and set <code>tcp_mem<\/code> to the result; you will either OOM or make the kernel throttle every connection. Instead, size <code>tcp_mem<\/code> as a fraction of usable RAM (a common starting point is the kernel&rsquo;s own auto-tuning, roughly 4%, 8%, 16% of RAM in pages) and confirm with <code>sockstat<\/code> that steady-state use stays below the first threshold.<\/p>\n<pre class=\"wp-block-code\"><code># example: cap TCP at ~12% of a 1 GB host (pages of 4 KB)\n# 1 GB = 262144 pages; 12% ~= 31457 pages\nsysctl -w net.ipv4.tcp_mem='8192 16384 31457'<\/code><\/pre>\n<h2 class=\"wp-block-heading\">The overcommit trap<\/h2>\n<p class=\"wp-block-paragraph\">Socket memory is kernel memory, but the pages backing user buffers come from the same pool. If <code>vm.overcommit_memory=1<\/code> is set (a common, badly-copied recommendation for Redis), the kernel hands out allocations it cannot guarantee. Under a burst of new connections that overcommit lets through, the host runs out of real RAM and the OOM killer chooses a victim &mdash; often your database, not the process that caused the spike. Check:<\/p>\n<pre class=\"wp-block-code\"><code>sysctl vm.overcommit_memory vm.overcommit_ratio\ngrep -E 'CommitLimit|Committed_AS' \/proc\/meminfo<\/code><\/pre>\n<p class=\"wp-block-paragraph\">If <code>Committed_AS<\/code> approaches <code>CommitLimit<\/code>, you are one allocation burst from the OOM killer regardless of how generous your socket buffers are. Keep <code>overcommit_memory<\/code> at 0 (heuristic) unless a specific application documents a need, and then watch <code>Committed_AS<\/code> continuously. This is one reason a fixed RAM ceiling makes buffer sizing a capacity question: our <a href=\"https:\/\/virtualserversvps.com\/\">performance VPS plans<\/a> lists plans by memory tier so you can pick an instance large enough that kernel socket memory never competes with the application.<\/p>\n<h2 class=\"wp-block-heading\">Bufferbloat versus memory pressure<\/h2>\n<p class=\"wp-block-paragraph\">Large socket buffers are not free wins. A connection that buffers hundreds of kilobytes in the kernel adds latency under congestion &mdash; the sender keeps pushing because the buffer still has room, even though the bottleneck link is already full. This is bufferbloat, and on a shared VPS uplink it manifests as elevated RTT for everyone on the host, not just the heavy connection. The modern answer is not larger buffers but smarter queue management: keep per-socket buffers close to the bandwidth-delay product of your actual paths and let AQM (fq_codel, cake) absorb the excess. Only raise <code>tcp_rmem<\/code> maximums when you have measured that the window is the limiter on a specific long-fat path, and then only for that service via per-socket <code>SO_RCVBUF<\/code> rather than a global sysctl.<\/p>\n<h2 class=\"wp-block-heading\">Monitoring the values that matter<\/h2>\n<p class=\"wp-block-paragraph\">Set up a small baseline so you notice drift before an incident. Track four signals: TCP memory use from <code>\/proc\/net\/sockstat<\/code>, retransmit and drop counters from <code>nstat<\/code>, <code>Committed_AS<\/code> versus <code>CommitLimit<\/code> from <code>\/proc\/meminfo<\/code>, and the memory-PSI stall counter. None of them is expensive to collect and together they tell the whole story: rising socket memory plus rising drops means the ceiling is too low; rising <code>Committed_AS<\/code> with flat socket memory means something else is leaking. A five-line collector writing to logs every minute will catch a slow leak long before it turns into an OOM kill. Treat buffer tuning as an iterative loop &mdash; change one value, observe for a full load cycle, then decide &mdash; not a one-shot configuration.<\/p>\n<h2 class=\"wp-block-heading\">Verify the change helped<\/h2>\n<p class=\"wp-block-paragraph\">Measure before and after with concurrent connection load, not a single transfer. Track drops and retransmits as well as throughput:<\/p>\n<pre class=\"wp-block-code\"><code>ss -s\nnstat -az | grep -E 'TcpRetransSegs|TcpExtListenDrops|TcpExtTCPBacklogDrop'<\/code><\/pre>\n<p class=\"wp-block-paragraph\">If <code>ListenDrops<\/code> and <code>BacklogDrop<\/code> rise with connection count, the problem is the accept queue, not buffer memory &mdash; increasing <code>tcp_rmem<\/code> will not fix it. Match the tuning to the symptom. If you are repeatedly hitting socket-memory ceilings, the honest answer may be that the instance is undersized; our <a href=\"https:\/\/virtualserversvps.com\/\">VPS comparison page<\/a> compares plans with the RAM headroom needed to buffer high connection counts without entering tcp_mem pressure. Set conservative defaults, instrument <code>sockstat<\/code> and <code>Committed_AS<\/code>, and raise buffers only when the data shows the kernel is the bottleneck.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your application, your page cache,&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1285","post","type-post","status-publish","format-standard","hentry","category-vps-guides-tutorials"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v26.1 (Yoast SEO v26.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap - Virtual Servers VPS Blog<\/title>\n<meta name=\"description\" content=\"Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap\" \/>\n<meta property=\"og:description\" content=\"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-03T23:08:43+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/\",\"name\":\"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-10-03T23:08:43+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"description\":\"Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your\",\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap - Virtual Servers VPS Blog","description":"Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/","og_locale":"en_US","og_type":"article","og_title":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap","og_description":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap","og_url":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-10-03T23:08:43+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/","url":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/","name":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-10-03T23:08:43+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"description":"Every byte the kernel buffers for TCP has to come from somewhere. On a VPS with a fixed RAM ceiling, socket buffers compete directly with your","breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/linux-socket-memory-tcp-mem-wmem-overcommit-tuning-vps\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Linux Socket Memory Tuning on a VPS: tcp_mem, tcp_wmem and the Overcommit Trap"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=1285"}],"version-history":[{"count":2,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1285\/revisions"}],"predecessor-version":[{"id":1293,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1285\/revisions\/1293"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}