Skip to main content
Card class: Sensitivity • Category: Capacity

​
At a glance

The proportion of the host’s memory currently in use by the MySQL instance and the operating system supporting it. Memory is the resource MySQL most wants and is the most dangerous to run out of: when a database host exhausts RAM it either starts swapping to disk (catastrophic for latency) or the kernel out-of-memory killer terminates the mysqld process outright (an instant outage). This card is the early-warning gauge for both failure modes. Because the InnoDB buffer pool is usually the largest single consumer, memory pressure here is tightly coupled to the buffer-pool cards.
What it tracksMemory in use as a percentage of total host memory. This is the host-level figure: it includes the InnoDB buffer pool, per-connection thread buffers (sort, join, read), the operating system page cache, and any co-resident processes.
Data sourceHost memory metrics for the instance. On self-managed hosts this is OS-level (/proc/meminfo, free -m); on Amazon RDS / Aurora the FreeableMemory CloudWatch metric (converted to a used percentage against instance class memory); on Google Cloud SQL the database/memory/utilization and components metrics in Cloud Monitoring.
Calculation basisused_memory / total_host_memory * 100. On managed services where only freeable memory is exposed, computed as (1 - FreeableMemory / instance_memory) * 100.
Time windowRT (real-time gauge).
Alert trigger> 85%. Above this the host has little headroom for connection spikes or query buffers, and the next surge risks swapping or an OOM kill. The 15% margin is the buffer the alert protects.
Rolesowner, engineering, operations

​
Calculation

The card expresses host memory in use as a percentage of total host memory: 
memory_usage_% = (used_memory / total_host_memory) * 100

on managed services exposing only freeable memory:
memory_usage_% = (1 - (FreeableMemory / instance_class_memory)) * 100
What goes into “used” and why it matters:
  1. The buffer pool dominates, by design. innodb_buffer_pool_size is typically set to 50 to 75% of host RAM on a dedicated database server, so the single largest line of memory usage is intentional and good. A host sitting at 70% steady usage that is mostly buffer pool is healthy. The alert is about headroom for the variable consumers, not about the buffer pool itself.
  2. Per-connection buffers are the variable, dangerous part. Each connection can allocate sort buffers, join buffers, and read buffers on demand. Total connection-driven memory scales with Connections In Use: a sudden connection storm (often from Connection Pool Saturation % climbing) can add gigabytes quickly. A host at 85% with the buffer pool fixed has little room to absorb such a storm.
  3. Page cache is reclaimable; the OOM killer still counts it carefully. On self-managed Linux, the OS page cache shows as “used” but is reclaimable under pressure. Vortex IQ reports the practical used figure; the meaningful danger line is when reclaimable cache plus free memory no longer covers a demand spike, which is what the 85% threshold approximates.

​
Worked example

A platform team runs MySQL 8.0 on a host with 32 GB RAM. innodb_buffer_pool_size is set to 20 GB (62.5% of RAM). Snapshot taken on 09 Apr 26 at 18:30 BST during an evening traffic peak.
ComponentApprox memory
InnoDB buffer pool20.0 GB
Per-connection buffers (480 active connections)4.8 GB
mysqld overhead + other global buffers1.6 GB
OS + page cache1.5 GB
Total used27.9 GB of 32 GB
memory_usage_% = 27.9 / 32.0 = 0.872 = 87.2%
The gauge reads 87.2%, above the 85% alert line, and Nerve Centre raises the sensitivity flag. Diagnosis and response:
  1. The buffer pool is fixed; connections are the swing factor. The 20 GB pool is constant. The pressure is coming from 480 active connections each holding sort / join buffers. Confirm with Connections In Use and Connection Pool Saturation %: if connections have jumped, the memory rise is connection-driven, and the risk is a further spike tipping the host into swap or an OOM kill.
  2. Immediate lever: cap the connection storm. A runaway connection count usually traces to an application connection pool that is not bounded, or slow queries holding connections open. Reducing max_connections is a blunt safety valve; the better fix is bounding the application-side pool and clearing the slow queries that are holding connections (see Slow-Query Rate %).
  3. Structural lever: rebalance the budget or upsize. If steady-state usage is chronically near 85% even at normal connection counts, the host is genuinely undersized for the workload. Either lower innodb_buffer_pool_size slightly to free headroom (at some cost to hit rate) or move to a larger instance class. Confirm the buffer pool is actually needed at its current size via InnoDB Buffer Pool Hit Rate % before shrinking it.
Decision trace for 87.2%:
  - buffer pool: fixed 20 GB (hit rate 99.9% -> correctly sized)
  - connections: 480 vs typical 150  -> connection storm is the driver
  Action (now):   bound the app connection pool; kill stuck slow queries
  Action (later): if storms recur, add RAM rather than shrink the pool
  Do NOT: blindly cut buffer pool while hit rate is healthy
Three takeaways:
  1. High memory usage is normal on a database host; the danger is the headroom, not the level. A 70% host that is mostly buffer pool is healthy; an 87% host with a connection storm is one spike away from an OOM kill.
  2. The variable risk is connections, not the buffer pool. When this card alerts, look first at connection count and per-connection buffers.
  3. Swapping and OOM are the two failure modes this card prevents. Both are far worse than the cache-efficiency cost of keeping a sensible memory margin.

​
Sibling cards merchants should reference together

CardWhy pair it with Memory UsageWhat the combination tells you
InnoDB Buffer Pool Hit Rate %The buffer pool is the largest memory consumer.High memory with a healthy hit rate means the pool is correctly sized; do not shrink it.
InnoDB Free PagesA full pool both raises memory use and empties the free list.Both near their limits means the pool is fully committed and the host has no slack.
Connections In UsePer-connection buffers are the variable memory driver.Memory rising with connections confirms a connection-driven spike, not a config change.
Connection Pool Saturation %Saturation precedes the memory spike from a connection storm.Saturation and memory rising together is the classic pre-OOM signature.
Slow-Query Rate %Slow queries hold connections (and their buffers) open longer.A slow-query spike inflating connection counts is a common hidden memory driver.
Database Disk Usage %Swapping links memory pressure to disk pressure.Memory maxed plus disk filling from swap is a compound-risk emergency.
MySQL Health ScoreThe composite that weights capacity headroom.Sustained memory pressure visibly pulls the composite down.

​
Reconciling against the source

Where to look in MySQL’s own / native tooling:
Self-managed Linux: free -m and /proc/meminfo for the host figure; SELECT * FROM sys.memory_global_total; and the sys.memory_by_thread_by_current_bytes view (requires performance_schema memory instruments enabled) for the MySQL-internal breakdown. Server-side budget: SELECT @@innodb_buffer_pool_size, @@max_connections, @@sort_buffer_size, @@join_buffer_size; to see the fixed and per-connection allocations behind the number. Amazon RDS / Aurora: the FreeableMemory and SwapUsage CloudWatch metrics, plus Performance Insights for the buffer-pool component. Google Cloud SQL: the database/memory/utilization and database/memory/total_usage metrics in Cloud Monitoring.
Why our number may legitimately differ from a native reading:
ReasonDirectionWhy
Page cache treatmentCard may read higherOn Linux, reclaimable page cache counts as “used” in some tools and as “available” in others; the card reports the practical used figure, which can sit above a free -m “used” column that excludes cache.
Freeable-memory derivationMarginalOn managed services the card derives usage from FreeableMemory against the instance class size; rounding of the published class memory can shift the percentage by a fraction.
Sampling instantEither directionMemory fluctuates with connection churn; a hand reading a moment apart from the card’s sample will differ.
Co-resident processesCard may read higherOn a shared host, non-MySQL processes count toward host usage; the card reflects total host pressure, which is what matters for OOM risk.
Cross-connector reconciliation:
CardExpected relationshipWhat causes divergence
Connections In UseMemory should track connection count above the fixed buffer-pool baseline.Memory rising while connections are flat points at a memory leak or a growing temp-table workload, not connection load.
InnoDB Buffer Pool Hit Rate %A correctly sized pool explains most of the baseline usage.High memory with a poor hit rate means the pool is too small AND the host is constrained: upsize, do not shrink.

​
Known limitations / FAQs

My host is at 75% memory and steady. Should I worry? Usually not. A dedicated database host is supposed to use most of its RAM, because the InnoDB buffer pool is deliberately sized to 50 to 75% of host memory and the OS page cache fills the rest. A steady 75% that is mostly buffer pool is healthy. The alert fires at 85% because that is where the variable consumers (connection buffers) no longer have safe headroom for a spike. What actually happens if memory hits 100%? One of two bad outcomes. On a host with swap enabled, MySQL pages out to disk and latency collapses, often by orders of magnitude, because random disk IO replaces RAM access. On a host without swap (common on managed services), the kernel out-of-memory killer terminates a process, frequently mysqld itself, causing an instant outage and crash recovery on restart. Both are far worse than keeping a memory margin, which is why the 85% line is conservative. Should I lower innodb_buffer_pool_size when this card alerts? Only as a last resort, and only after checking InnoDB Buffer Pool Hit Rate %. Shrinking the pool frees memory but lowers the hit rate, pushing more reads to disk and raising latency. If the alert is driven by a connection storm, the right fix is bounding connections, not shrinking the pool. Shrink the pool only when the host is chronically constrained and upsizing is not an option. Why does memory climb when connections climb? Each connection can allocate per-statement work buffers (sort, join, read) on demand, and these are not shared. A connection storm therefore adds memory roughly in proportion to active connections holding heavy queries. This is why a runaway application connection pool, or slow queries holding many connections open, is the most common cause of a sudden memory spike. See Connections In Use. The card reads higher than free -m says is used. Is it wrong? No, the difference is usually page-cache accounting. Linux counts reclaimable page cache as “used” in some views and as “available” in others. The card reports the practical used figure that matters for OOM risk. For the MySQL-internal breakdown that excludes OS cache, use sys.memory_global_total and the sys.memory_by_thread_by_current_bytes view with performance_schema memory instruments enabled. Does the buffer pool shrink automatically under memory pressure? No. innodb_buffer_pool_size is a fixed allocation; MySQL does not shrink it on demand (online resizing exists but is an explicit operation, not automatic). This is precisely why the variable consumers (connections) are the danger: the largest block of memory is immovable, so a spike has to come out of the remaining headroom. Plan the memory budget assuming the pool is constant.

​
Tracked live in Vortex IQ Nerve Centre

Memory Usage % is one of hundreds of KPI pulses Vortex IQ tracks across MySQL and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.