{"id":1623,"date":"2026-11-07T07:35:31","date_gmt":"2026-11-07T07:35:31","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1623"},"modified":"2026-11-07T07:35:31","modified_gmt":"2026-11-07T07:35:31","slug":"kernel-dmesg-ring-buffer-size-tuning-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/","title":{"rendered":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Run <code>dmesg | head -5<\/code> on a VPS that has been up for three weeks and the timestamps will read a few days ago, not boot. The kernel log ring buffer is a fixed circular allocation, and on a chatty host with virtio, br_netfilter and conntrack messages it wraps quickly. The classic symptom is <code>dmesg | grep -i 'Out of memory'<\/code> returning nothing because the OOM record scrolled out hours after the incident. <code>sysctl kernel.dmesg_restrict<\/code> and <code>cat \/proc\/sys\/kernel\/printk<\/code> control access and console verbosity, but the buffer size itself lives in the kernel configuration and, on modern kernels, in a boot parameter.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This article covers how to size the buffer, how to persist it across reboots on a VPS, and how to ship the records elsewhere so that the kernel never becomes your only forensic source again. It is aimed at operators running 1\u20138 vCPU instances where memory is real and a 16 MiB log buffer is not free.<\/p>\n\n\n<!-- wp:heading level=\"2\" -->\n<h2>Reading the Current Ring Buffer Size<\/h2>\n<!-- \/wp:post-content -->\n\n<!-- wp:paragraph -->\n<p>The authoritative value is <code>LOG_BUF_LEN<\/code>, compiled into the kernel and reported at boot. Check it with <code>dmesg | grep -i 'log_buf_len'<\/code> or, more reliably, by inspecting the kernel command line:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>cat \/proc\/cmdline\ndmesg --kernel --level=info | grep -i 'Memory:.*available\\|log_buf_len'\nzcat \/proc\/config.gz 2&gt;\/dev\/null | grep CONFIG_LOG_BUF_SHIFT\n# fallback on non-rt kernels:\nsysctl kernel.printk<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>A <code>CONFIG_LOG_BUF_SHIFT<\/code> of 18 means 2^18 = 262144 bytes, roughly 256 KiB. Distributions such as Debian and Ubuntu ship 17 or 18, which is often under an hour of runtime on a host with multiple cloud-init and virtio_net messages per second. If <code>\/proc\/config.gz<\/code> is absent, the boot-time value is still visible in the early <code>dmesg<\/code> output as <code>log_buf_len: ... bytes<\/code> when the <code>log_buf_len=<\/code> parameter was supplied.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Setting log_buf_len on the Kernel Command Line<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The buffer can be enlarged at boot without recompiling, via the <code>log_buf_len=N<\/code> parameter. The value must be a power of two and is rounded up by the kernel. On GRUB-based systems, edit the default entry in <code>\/etc\/default\/grub<\/code>:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code># \/etc\/default\/grub\nGRUB_CMDLINE_LINUX_DEFAULT=\"consoleblank=0 log_buf_len=4M\"\n\nupdate-grub            # Debian\/Ubuntu\n# grub2-mkconfig -o \/boot\/grub2\/grub.cfg   # RHEL family\nreboot\ndmesg | grep -i 'log_buf_len'   # confirm: should show 4194304<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>4 MiB is a sensible default for a 2\u20134 GiB VPS and typically buys 12\u201348 hours of runtime depending on message rate. On instances with heavy conntrack or a KVM host that passes through a lot of virtio interrupts, 8 MiB is a reasonable ceiling. Above 16 MiB, the trade-off is that the buffer is allocated from low kernel memory at boot and is not reclaimable.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Why Entries Disappear Even with a Larger Buffer<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Space is only one reason records vanish. Message rate matters more. A single <code>iptables -L<\/code> rule set with logging, or a misconfigured <code>conntrack<\/code> table, can emit thousands of lines per minute. Benchmark your own rate with a quick count of lines per uptime hour:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>boot=$(date -d \"$(uptime -s)\" +%s)\nnow=$(date +%s)\nlines=$(dmesg | wc -l)\necho \"lines\/min: $(( lines * 60 \/ (now - boot) ))\"<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>If the answer exceeds roughly 200 lines per minute, no buffer size will hold a week of history. The correct fix is to stop the noisy source: silence <code>xt_LOG<\/code> rules you no longer need, set <code>kernel.printk_ratelimit<\/code> and <code>kernel.printk_ratelimit_burst<\/code> to throttle bursts, and check whether <code>nf_conntrack<\/code> is logging table-full events repeatedly.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Rate limiting is not the same as dropping the incident you care about. Printk rate limiting applies per emitting site for WARN and INFO levels, so genuine OOM or ext4 errors still come through. Combine it with a console loglevel of 4 (<code>sysctl -w kernel.printk=\"4 4 1 7\"<\/code>) so that only warnings and above reach the buffer from debugging paths.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Persisting Kernel Logs to Disk and Remote<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The ring buffer should never be the primary store. systemd-journald reads <code>\/dev\/kmsg<\/code> and writes a persistent journal, and rsyslog with <code>kern.*<\/code> can forward to a central collector. Enable persistent journal storage and cap its size so a VPS disk does not fill:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code># \/etc\/systemd\/journald.conf\n[Journal]\nStorage=persistent\nSystemMaxUse=500M\nSystemMaxFileSize=50M\nRateLimitIntervalSec=30s\nRateLimitBurst=2000\n\nsystemctl restart systemd-journald\njournalctl -k -b -1 --no-pager | tail -20<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>-b -1<\/code> flag lists messages from the previous boot, which is exactly the archive the ring buffer cannot provide after a reboot. For hosts that reboot unexpectedly, <code>journalctl -k -b -1 -p err<\/code> after recovery is the fastest path to the cause. If disk space is tight, allow the journal a 500 MiB ceiling and periodically verify with <code>journalctl --disk-usage<\/code>.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Kernel Panic and Oops Capture<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>A kernel panic reboots the machine and, unless configured otherwise, leaves no trace in the next boot. Two sysctls matter: <code>kernel.panic<\/code> sets the seconds to wait before reboot, and <code>kernel.panic_on_oops<\/code> decides whether an oops escalates. To capture a crash dump, either use <code>kdump<\/code> with a reserved crashkernel region or persist <code>pstore<\/code> to a backing device.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sysctl -w kernel.panic=10\nsysctl -w kernel.panic_on_oops=1\nsysctl -w kernel.panic_print=1\n# verify pstore availability\nmount | grep pstore\nls -l \/sys\/fs\/pstore\/<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p><code>panic_print=1<\/code> prints the task list before reboot, which is invaluable when the console log is the only surviving evidence. On virtualised hardware, pstore is rarely available, so a serial console or <code>netconsole<\/code> feed to another host is the more reliable channel.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Container and Cloud-Init Noise<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Two sources dominate message volume on a fresh VPS image. <code>cloud-init<\/code> logs each datasource probe at INFO level, and Docker or containerd emit network setup messages per container start. On an instance that runs containers with restart policies, a flapping health check can produce thousands of veth and iptables lines per hour and wrap the buffer on its own.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Cap cloud-init verbosity with <code>log_verbosity: warn<\/code> in <code>\/etc\/cloud\/cloud.cfg.d\/05_logging.cfg<\/code>, and keep its output journal-routed rather than console-routed. For container noise, retain the messages that matter (OOM, link down) but let the container runtime&#8217;s log driver absorb per-start chatter instead of writing it to kmsg.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading level=\"2\" -->\n<h2>Verifying the Change Under Load<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>After a reboot, confirm the new buffer size and measure how long it takes to wrap under realistic conditions. A simple check is to note the oldest timestamp and watch the delta grow:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>dmesg -T | head -1\ndmesg -T | tail -1\n# oldest-to-newest span in seconds\ndmesg -T | awk 'NR==1{split($0,a,\" \");t0=$0} END{}' &gt;\/dev\/null\njournalctl -k --since \"-1h\" | wc -l<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Record the span before and after the change. On a small instance the increase from 256 KiB to 4 MiB typically multiplies retention by 15\u201320x once noise has been trimmed. Keep an eye on <code>\/proc\/meminfo<\/code> <code>Slab<\/code> growth to confirm the larger buffer is not causing pressure alongside other kernel allocations.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Sizing the buffer is only one part of keeping a small instance observable; the memory cost of the change matters too. If you are budgeting RAM across a fleet, see our <a href=\"https:\/\/virtualserversvps.com\/cloud-vps-benefits\">cloud VPS benefits breakdown<\/a> for how fixed kernel overhead compares with workload headroom. And when logs need to outlive the host itself, forwarding to a collector is cheaper than growing the buffer indefinitely\u2014compare the <a href=\"https:\/\/virtualserversvps.com\/managed-vs-unmanaged\">managed vs unmanaged<\/a> options if you would rather not operate that pipeline yourself.<\/p>\n<!-- \/wp:paragraph -->","protected":false},"excerpt":{"rendered":"<p>A fixed-size ring buffer silently drops the boot logs and OOM records you need most. Here is how to size log_buf_len, throttle printk, and persist captures.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1623","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>Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish - Virtual Servers VPS Blog<\/title>\n<meta name=\"description\" content=\"A fixed-size ring buffer silently drops the boot logs and OOM records you need most. Here is how to size log_buf_len, throttle printk, and persist captures.\" \/>\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\/kernel-dmesg-ring-buffer-size-tuning-vps\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish\" \/>\n<meta property=\"og:description\" content=\"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-11-07T07:35:31+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=\"6 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/\",\"name\":\"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-11-07T07:35:31+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"description\":\"A fixed-size ring buffer silently drops the boot logs and OOM records you need most. Here is how to size log_buf_len, throttle printk, and persist captures.\",\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish\"}]},{\"@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":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish - Virtual Servers VPS Blog","description":"A fixed-size ring buffer silently drops the boot logs and OOM records you need most. Here is how to size log_buf_len, throttle printk, and persist captures.","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\/kernel-dmesg-ring-buffer-size-tuning-vps\/","og_locale":"en_US","og_type":"article","og_title":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish","og_description":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish","og_url":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-11-07T07:35:31+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/","url":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/","name":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-11-07T07:35:31+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"description":"A fixed-size ring buffer silently drops the boot logs and OOM records you need most. Here is how to size log_buf_len, throttle printk, and persist captures.","breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/kernel-dmesg-ring-buffer-size-tuning-vps\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Tuning the dmesg Ring Buffer on a VPS: Why Boot Logs Vanish"}]},{"@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\/1623","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=1623"}],"version-history":[{"count":1,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1623\/revisions"}],"predecessor-version":[{"id":1630,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1623\/revisions\/1630"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}