Memcached in WSL: Slabs, Evictions, and Volatile Cache Tests

Memcached is a high-performance in-memory key-value cache, not a durable database. Running it in WSL is useful for testing cache clients and application invalidation logic from a Linux development environment. The cache process can disappear when its service or WSL distribution stops, and entries may be evicted before then. Any authoritative state must remain in the application’s source of truth.

The useful operational question is not merely whether the daemon responds. It is whether the application tolerates misses, expirations, evictions, reconnects, and a cold cache without returning incorrect or unsafe results. A successful local set/get demonstrates a protocol path; it does not validate cache consistency or business correctness.

Start one package-managed daemon

Install Memcached from the distro package manager and record the actual package version. Inspect the service command and unit before changing memory limits or bind behavior:

memcached -V
systemctl status memcached --no-pager
sudo systemctl start memcached
systemctl is-active memcached

If running a disposable foreground instance is appropriate, the daemon supports options for memory capacity, port, and listener address. Do not launch that command while the package unit already owns the same port and memory:

memcached -m 128 -p 11211 -l 127.0.0.1

This foreground example is for an isolated local test only. Package defaults, service users, and unit flags can differ. The memory option configures the item cache allocation; it does not cap every byte used by the process, kernel, client applications, or the WSL VM.

Test cache behavior without confusing it with persistence

Exercise the application client against a dedicated local namespace. Verify a miss, a set, a hit, an expiration, and a delete. Give test keys a short prefix and TTL so cleanup cannot affect another developer’s workload.

The text protocol offers a simple operational view of daemon state:

printf 'stats\r\nstats slabs\r\nquit\r\n' | nc -w 2 127.0.0.1 11211

The server returns STAT lines followed by END. Inspect values such as current items, bytes, evictions, reclaimed items, and per-slab statistics as trends, not as a one-time health verdict. Counter names and detail can vary by version; use the current protocol reference for interpretation.

Memcached is intentionally volatile. Restarting the daemon or stopping WSL loses its in-memory items; there is no database backup to restore. If an application cannot reconstruct its state after a cache miss, that data was not safely modeled as cache state. Do not write a runbook that copies cache files because there are no durable cache contents to preserve.

Understand slabs before reacting to evictions

Memcached allocates item memory in slab classes based on item size. An item that expires or is evicted can free capacity within a slab class without making that capacity available to a different class in the way an operator might expect. A global free-memory number can therefore obscure pressure in a particular item-size class.

Use per-slab and item statistics to correlate the application’s key/value sizes with slab activity. An increasing eviction count may mean the cache is doing its job under the configured memory cap, or it may mean a working set is larger than intended, TTLs are too long, or keys are leaking. It is not automatically an outage. Pair those counters with hit/miss rates, latency, application cache-miss behavior, and the relevant slab metrics.

Do not respond to every eviction by increasing the memory allocation. In WSL, a larger Memcached reservation competes with other Linux processes and the Windows host. First measure which keys and slab classes are under pressure, whether old entries have meaningful TTLs, and whether the application caches oversized or low-value payloads. Then make a bounded change and compare the same workload.

Expiration is not a precise timer callback for application logic. An expired value should be treated as unavailable when accessed, but memory reclamation and slab reuse are separate allocator behavior. The cache should never be the only record of a deadline, payment, job, or other authoritative state transition.

The slab allocator can expose a useful failure pattern: one class may report evictions while another has free pages, because pages are organized around item-size classes and reassignment is a separate allocator decision. Compare item sizes, chunk sizes, page counts, and per-class eviction rates. A single global evictions counter does not tell you whether the application is losing useful entries, whether TTL expiration is doing expected cleanup, or which key population is responsible.

Make cache keys and values observable without logging sensitive payloads. Add a bounded diagnostic that samples key prefixes, encoded value sizes, TTLs, and cache outcome counts. Do not dump complete application values from a shared development cache. A local load test should use a realistic key-size distribution; uniform tiny strings hide allocator behavior that large JSON or serialized objects can trigger.

Memcached’s flush_all command marks items expired; it does not promise that all memory is immediately returned to the operating system. A sudden drop in item count therefore need not be followed by an equal drop in process memory. Treat flush as a cache invalidation operation, not a memory-compaction tool, and never issue it against an instance shared with unrelated tests.

Design the client contract for misses and stale data

A cache-aside client should fall back to the source of truth on a miss, then decide whether and how to populate the cache. Invalidation must account for concurrent writes: a delayed cache fill can repopulate an older value after an invalidation. If that can violate correctness, use an explicit versioning or consistency strategy rather than assuming deletion guarantees freshness.

Use bounded network timeouts and a clear failure policy. If Memcached is unavailable, the application may bypass caching, fail a request, or serve stale data depending on product requirements. Each option has load and correctness consequences. A cache outage can increase load on the backing database, so test fallback with enough control to avoid overwhelming a shared local or remote dependency.

Test stampede behavior deliberately. If many requests see the same expired key, they may all query the origin at once. The application can use coalescing, a short stale-while-revalidate window, or another domain-appropriate mechanism, but must still preserve correctness. Keep the cache-miss path bounded and instrument origin request volume; otherwise a local cache experiment may pass at one client and collapse under parallel tests.

Never use broad flush operations against a cache shared by unrelated applications. A flush is suitable only for an isolated disposable instance and still does not substitute for testing TTL and key invalidation behavior. Namespacing test keys makes cleanup safer and makes statistics easier to attribute.

Keep WSL memory and disk semantics in view

Memcached’s item allocation is in guest memory, which ultimately competes for the WSL VM and Windows host resources. Monitor Linux process memory alongside WSL’s configured memory ceiling and overall host pressure. The cache may hold fewer usable items than the nominal allocation due to metadata and item overhead.

Unlike persistent databases, Memcached does not grow a VHDX with item contents, but logs, package files, and test artifacts still consume distro disk. Do not infer that a running cache is independent from WSL lifecycle: host sleep, restart, servicing, or explicit shutdown terminates the service and empties the in-memory working set.

Acceptance criteria for a local cache dependency

Accept the setup when a clean distro starts one package-owned daemon, the application client can exercise miss/set/hit/expiry/delete behavior, daemon statistics are interpretable under a controlled load, and the application remains correct after the cache is stopped and restarted. Confirm that the test uses disposable keys and that no authoritative data depends on cache retention.

Record the Memcached version, service configuration, memory allocation, client timeout, key namespace, TTL policy, and expected fallback behavior. Do not describe Memcached as a durable queue or database. For shared environments, deploy and monitor the cache according to the target platform’s service lifecycle and data-protection requirements.

Related:

Sources: