Lecture 4: Memcached Setup and Tuning

Introduction to Memcached's Philosophy

Before diving into the specifics of hardware, it's crucial to understand the design philosophy of Memcached. It is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. Memcached is, at its core, a simple key-value store. It is designed for one primary purpose: to be fast. This speed is achieved through simplicity and by operating entirely in memory. Unlike Redis, which offers data persistence, or more complex systems like Apache Ignite, Memcached is ephemeral. If the server restarts, the cache is empty. This design choice has profound implications for its hardware requirements.

As Jainandunsing (2025) notes, Memcached is a "lightweight, blazing-fast in-memory key-value store... even leaner than Redis, making it perfect for on-prem, low-resource environments." This leanness is its greatest strength. It does one thing, and it does it exceptionally well: store and retrieve arbitrary data (strings, objects) from RAM based on a key.

Core Hardware Components Analyzed

When provisioning a server for Memcached, your focus will be overwhelmingly on one component: Random Access Memory (RAM). The other components are important for a stable system, but they are secondary to the primary function of the cache.

1. Random Access Memory (RAM)

RAM is the lifeblood of Memcached. Since all cached data resides in memory, the amount of RAM you allocate directly determines the size of your cache. Insufficient RAM is the most common cause of poor cache performance, leading to a high rate of evictions (where old items are discarded to make room for new ones). This defeats the purpose of the cache, as it forces the application to fall back to the slower, primary data source (like a database) more frequently.

How to Estimate RAM Needs: A precise calculation is difficult without profiling your application, but a good estimate can be derived from the following formula:
Estimated RAM = (Average Object Size in bytes * Number of Objects to Cache) * Overhead Factor
The Overhead Factor (typically 1.1 to 1.3) accounts for Memcached's own internal data structures, keys, and metadata associated with each item. For session caching, the calculation is more direct:
Estimated RAM = (Average Session Size * Peak Concurrent Users) * 1.2
For a small application with 20 users and an average session size of 5KB, this would be `(5KB * 20) * 1.2 = 120KB`. This illustrates why Memcached can run on such minimal hardware for smaller use cases. For a large e-commerce site with 50,000 concurrent users and 20KB sessions, the requirement jumps to `(20KB * 50000) * 1.2 = 1.2 GB`, just for session data. This calculation highlights the need to understand your data and traffic patterns.

2. Central Processing Unit (CPU)

Memcached is not CPU-intensive. Its operations (get, set, delete) are computationally simple. The server is multi-threaded, meaning it can leverage multiple CPU cores to handle concurrent connections. However, a single, modern CPU core is often sufficient for tens of thousands of requests per second. For most workloads, a minimal configuration of 1-2 cores is adequate. The primary benefit of more cores is handling a very high number of simultaneous client connections, not speeding up individual operations. The provided context suggests a minimum of "1 core (Intel/AMD @ 2.0+ GHz)," which is a very modest requirement for any modern server.

3. Storage (Disk)

Disk performance is largely irrelevant to Memcached's caching operations. As stated in the provided materials, "Memcached is entirely in-memory, no disk storage needed for data." The only storage requirements are for the operating system, the Memcached binaries, and system logs. A small, fast SSD (10-20 GB) is more than sufficient, primarily to ensure the underlying OS is responsive.

4. Network

While CPU is not a bottleneck, the network certainly can be. Memcached's performance is measured in sub-millisecond response times. This speed is lost if the network introduces latency.

• Latency: This is the most critical network metric. The cache server should be as close as possible to the application servers, ideally within the same rack or data center availability zone. A low-latency 1 Gbps connection is a standard baseline.
• Throughput: For applications caching very large objects or handling extremely high request volumes, a 1 Gbps connection could become saturated. In such high-performance scenarios, upgrading to 10 Gbps or faster networking may be necessary.

Special Use Case: Memcached on a Raspberry Pi

The efficiency of Memcached is best demonstrated by its ability to run effectively on low-power, single-board computers like the Raspberry Pi. This makes it an excellent choice for home labs, small projects, or IoT applications where a lightweight, shared memory store is needed. The hardware requirements are incredibly modest and align perfectly with the capabilities of recent Pi models. Running Memcached on a Pi is not just possible; it's a practical solution for specific use cases like caching session data for a small internal web application or caching frequent API responses from an external service to avoid rate limiting.

Installation and Initial Setup

Getting Memcached running on a modern Linux distribution, such as Ubuntu or Debian, is a straightforward process using the system's package manager. The installation provides the Memcached server daemon, command-line tools for interacting with it, and a default configuration file that we will tune for our needs.

The first step is always to ensure your system's package list is up-to-date.

sudo apt update && sudo apt upgrade -y

Next, install the Memcached daemon and the `libmemcached-tools` package, which provides helpful command-line utilities for testing and administration.

sudo apt install memcached libmemcached-tools -y

Once installed, the Memcached service will typically start automatically with a default configuration. However, these defaults are rarely optimal for a production environment. Our next step is to customize the configuration to match our hardware and security requirements.

Dissecting the Configuration File

The main configuration for Memcached on Debian-based systems is located at /etc/memcached.conf. This file contains the startup parameters passed to the Memcached daemon. Let's explore the most critical directives you will need to tune.

sudo nano /etc/memcached.conf

• -m <memory_in_mb>: Memory Allocation. This is the most important setting. It specifies the maximum amount of RAM, in megabytes, that Memcached is allowed to use for storing items. The default is often a conservative 64MB. You should set this value based on your hardware analysis from Section 1, leaving enough memory for the operating system and other processes. For a server with 2GB of RAM dedicated to caching, you might set this to -m 1536.
• -l <ip_address>: Listen Address. By default, Memcached listens on `127.0.0.1` (localhost), which is secure as it only allows connections from the same machine. If your application servers are on different machines, you must change this to the private IP address of the cache server (e.g., `-l 192.168.1.100`). Warning: Never set this to `0.0.0.0` or a public IP address without a firewall, as Memcached has no authentication and would be open to the world.
• -p <port>: Port Number. The default port is `11211`. There is rarely a need to change this unless it conflicts with another service or for "security by obscurity" (which is not a real security strategy).
• -u <user>: User. For security, Memcached should not run as the `root` user. The installation typically creates a `memcache` user. This directive ensures the process drops its root privileges after starting, which is a critical security best practice.
• -t <threads>: Worker Threads. This sets the number of threads Memcached will use to process requests. The default is often 4. A good starting point is to set this to the number of CPU cores available on your server. For a 2-core machine, you would set `-t 2`. Increasing this beyond the number of cores can introduce context-switching overhead with diminishing returns.
• -c <max_connections>: Max Connections. This defines the maximum number of concurrent client connections. The default is 1024. If you have many application servers or your application uses persistent connections, you may need to increase this. Monitor the `curr_connections` stat to see if you are approaching this limit.
• -U 0: Disable UDP. The Memcached protocol can operate over both TCP and UDP. However, the UDP port has been historically exploited in DDoS amplification attacks. Unless you have a specific, trusted use case for UDP, it is highly recommended to disable it for security by setting the value to 0.
• -v, -vv, -vvv: Logging Verbosity. These flags increase the amount of information Memcached logs to syslog. `-v` provides basic error and warning messages. `-vv` adds client command and response logging, which is useful for debugging but can generate a lot of log data. `-vvv` is for deep debugging and logs internal state transitions. Use these flags temporarily when troubleshooting.

Service Management and Verification

After editing the configuration file, you must restart the Memcached service for the changes to take effect. You should also enable the service to ensure it starts automatically on server reboot.

sudo systemctl restart memcached
sudo systemctl enable memcached

To verify that the service is running correctly and using your new configuration, check its status:

sudo systemctl status memcached

The most direct way to confirm Memcached is operational is to connect to it and request its statistics. The `netcat` (`nc`) tool is perfect for this.

echo "stats" | nc localhost 11211

This command sends the string "stats" to the Memcached server on port 11211 and prints the response. The output will be a list of key-value pairs describing the server's state, including its uptime, version, current connections, memory usage, and hit/miss counters. Seeing this output is a definitive confirmation that your cache server is up and running.

The Case for Caching Sessions

In a traditional web application, user session data is often stored in files on the web server's local disk or in a relational database. While simple, this approach has significant drawbacks in a modern, scalable architecture. File-based sessions prevent easy load balancing across multiple web servers, as a user's session is tied to a single machine. Database-backed sessions solve this but introduce significant latency, adding a database query to nearly every user request. This is where Memcached excels.

By using Memcached as a session store, you create a centralized, high-speed, in-memory repository for session data that all your application servers can access. This decouples user state from the application servers, allowing for seamless scaling and fault tolerance. A request from a user can be handled by any application server, which can instantly retrieve the session data from Memcached, process the request, and write the updated session back. This drastically reduces database load and improves application response time.

Integrating Memcached with Web Applications

Most modern web frameworks and languages have robust, well-supported libraries for integrating Memcached as a session handler. The configuration is typically minimal, requiring only that you point the application to the Memcached server's address and port.

Deep Dive: Memcached's Memory Management - The Slab Allocator

To effectively tune Memcached, you must understand how it manages memory. Unlike systems that use `malloc()` and `free()` for every object, which can lead to memory fragmentation, Memcached employs a mechanism called the slab allocator.

Here's how it works:

1. Slabs and Pages: On startup, Memcached carves the total memory allocated to it (`-m`) into large 1MB blocks called "pages".
2. Slab Classes: These pages are then assigned to different "slab classes". Each slab class is responsible for storing items of a specific size range. For example, one class might handle items between 97-128 bytes, the next 129-160 bytes, and so on.
3. Chunks: Within a page, the memory is divided into equal-sized "chunks" appropriate for that slab class. All chunks in a given slab class are the same size.
4. Storage: When you store an item, Memcached finds the smallest slab class that can accommodate the item's size and places it into a free chunk within that class.

This pre-allocation strategy is extremely fast and completely eliminates memory fragmentation. However, it can lead to wasted memory if your item sizes are poorly distributed. For example, if you store a 130-byte item in a slab class with 160-byte chunks, 30 bytes of that chunk are wasted and cannot be used by any other item.

Tuning the Slab Allocator

For most general-purpose use cases, the default slab settings are sufficient. However, in high-performance environments, you can tune them with startup flags:

• -f <factor>: Growth Factor. This controls the size progression between slab classes. The default is 1.25. A smaller factor creates more slab classes with finer-grained size differences, potentially reducing wasted memory but increasing overhead.
• -n <bytes>: Minimum Chunk Size. This sets the size of the smallest chunk. The default is 48 bytes.

You can inspect the state of your slabs using the `stats slabs` command. This will show you how many chunks are used in each class, how much memory is allocated, and how much is wasted. If you see that certain slab classes are full and causing evictions while others are mostly empty, it might indicate a need for tuning or, more likely, an increase in total memory.

Eviction Policy: Least Recently Used (LRU)

What happens when a slab class runs out of free chunks? Memcached applies its one and only eviction policy: Least Recently Used (LRU). It identifies the item within that specific slab class that has not been accessed for the longest time and discards it to make room for the new item. This is a simple but effective "survival of the fittest" strategy for your data. The `evictions` counter in the main `stats` output is a critical health metric. A consistently rising number of evictions is a clear signal that your cache is too small for your workload or your item Time-to-Live (TTL) values are too long.

Monitoring and Performance Metrics

Continuous monitoring is key to maintaining a healthy cache. The most important metrics to track are:

• Cache Hit Ratio: This is the percentage of `get` requests that are successful (`get_hits`). A healthy cache should have a hit ratio of 90% or higher. Formula: `(get_hits / (get_hits + get_misses)) * 100`. A low hit ratio means your application is frequently going to the database, negating the benefits of the cache.
• Evictions: As mentioned, this should be at or near zero. If it's climbing, you need more memory.
• Memory Usage (bytes): Track this against your `limit_maxbytes` to understand how full your cache is.
• Current Connections (curr_connections): Ensure this stays comfortably below your configured maximum (`-c`).