Memcached Setup and Tuning

How can a simple in-memory cache make your database-driven application 10x faster?

Objectives & Success Criteria

By the end of this lesson, you will be able to:

  • Analyze Memcached hardware requirements for different workloads.
  • Configure a secure, production-ready Memcached instance.
  • Integrate Memcached for high-performance session caching.
  • Tune memory allocation and monitor key performance metrics.

Lesson Roadmap

A horizontal timeline showing the five sections of the lesson. Sizing Config Caching Tuning Summary

Concept 1: What is Memcached?

A high-performance, distributed, in-memory key-value store. Its primary goal is speed, achieved by keeping all data in RAM. It's ephemeral—data is lost on restart—making it perfect for caching temporary data to reduce database load.

Cache-Aside Pattern Flowchart Application Caching Flow Web App Memcached Database 1. GET key 2. CACHE HIT: Return Value 1a. GET key 2a. CACHE MISS 3. Query Database 4. Return Data 5. SET key

Concept 2: Sizing Your Cache

Memcached's performance hinges on RAM, which directly dictates cache size. CPU and disk needs are minimal; a single core and a small SSD for the OS suffice. Low-latency networking is the other critical component for fast response times.

Memcached Hardware Priorities Diagram Hardware Component Priority 1. RAM Determines Cache Size (Avg Object Size * # Objects) * 1.2 The most critical component. More RAM = fewer evictions. 2. Network Low latency is key (e.g., 1-10 Gbps) 3. CPU Lightweight; 1-4 cores is often enough. 4. Storage (OS/Logs only)

Concept 3: Essential Configuration

Configuration is managed via startup flags in /etc/memcached.conf. The most critical are -m (memory), -l (listen IP for security), -t (threads for concurrency), and -c (max connections).

Visualizing memcached.conf Key Configuration Directives # /etc/memcached.conf -m 4096 -l 192.168.1.100 -p 11211 -u memcache -t 4 -c 2048 -U 0 -m (Memory) Allocate 4GB of RAM for data -l (Listen IP) Bind to private IP for security -t (Threads) Match worker threads to CPU cores -U (UDP Port) Disable UDP to prevent attacks

Example: Production Config

For a server with 4 cores and 8GB RAM, listening on a private network:


# /etc/memcached.conf

# 1. Allocate 6GB of RAM for item storage.
-m 6144

# 2. Listen on the server's private network IP.
-l 192.168.1.100

# 3. Run as the non-privileged 'memcache' user.
-u memcache

# 4. Use 4 worker threads, matching the number of CPU cores.
-t 4

# 5. Increase max connections for a large app cluster.
-c 4096

# 6. Disable the UDP port for security.
-U 0

Concept 4: The Slab Allocator

Memcached avoids memory fragmentation with a slab allocator. It divides its total memory into 1MB "pages," which are then subdivided into fixed-size "chunks" organized by "slab classes." Items are stored in the smallest possible chunk, ensuring fast allocation.

Memcached Slab Allocator How the Slab Allocator Manages Memory 1. Total Memory Allocated (-m) Page 1 Page 2 ... many 1MB pages ... Page N 2. Pages are assigned to Slab Classes Slab Class 5 (Items 97-128 bytes) Page 2 Memory 3. Each Page is divided into fixed-size Chunks Chunk (128b) Chunk (128b) Chunk (128b) ... 4. Item is stored in smallest fitting chunk SET key (105 bytes) 105 bytes used 23 wasted

Concept 5: Performance Tuning

When memory is full, Memcached evicts the Least Recently Used (LRU) item. Monitor the Cache Hit Ratio (ideally >90%) to measure effectiveness and Evictions (ideally 0) to know when you need more RAM.

Healthy Cache Performance Dashboard Healthy Cache Dashboard Cache Hit Ratio 95% (get_hits / cmd_get) Evictions 0 0 Should be consistently zero Memory Usage 4.9GB / 6GB (82%) Connections 153 curr_connections

Interactive Check

Are the following statements True or False?

  • You should bind Memcached to a public IP (0.0.0.0) for easy access.
    False. This is a major security risk. Always bind to a private IP.
  • If your cache hit ratio is low, the first step is always to add more RAM.
    False. It could also be a poor caching strategy (e.g., wrong keys, short TTLs).
  • Memcached's slab allocator is designed to prevent memory fragmentation.
    True. Pre-allocating chunks of specific sizes avoids fragmentation.

Common Misconceptions

  • Error: Exposing Memcached to the internet.
    Correction: Bind to a private IP (-l) and use a firewall. Memcached has no built-in authentication.
  • Error: Ignoring evictions.
    Correction: A rising eviction count means you need more memory (-m) or shorter item TTLs. It's the #1 sign of an undersized cache.
  • Error: Assuming more threads (-t) is always better.
    Correction: Match thread count to CPU cores to avoid performance loss from context-switching overhead.

Summary & Key Takeaways

  • RAM is the most critical resource; size it carefully based on your application's data and traffic patterns.
  • Prioritize security: always bind to a private IP, run as a non-root user, and disable the UDP port.
  • Understand the slab allocator and LRU eviction to diagnose memory pressure and performance issues.
  • Continuously monitor your cache hit ratio and eviction count to gauge the health and effectiveness of your cache.

Exit Ticket

You check your production Memcached stats and see a high and constantly rising evictions count.

What are the first two things you would investigate, and what actions would you take?