The use of Memcached and its memory management functions are often considered critically important to the functionality of many websites. After you have it configured on a basic level, you may find that your website needs some more specific tuning to get the greatest use out of it. To get this additional use, learn more about:
- How Memcached works
- Pages, slab classes and chunks
- Advanced Memcached configuration
- Memcached and multisite applications
- Other recommendations
How Memcached works
Memcached is a scalable, in-memory key-value store. As applications grow to accommodate more traffic (including data and requests), Memcached can be scaled by adding more servers (also called horizontal scaling) — something that is difficult to do with MySQL. The Memcached store can be distributed across multiple servers, all representing a single storage pool of cached data. Each server contains an associative array that represents a part of the pool. The Memcached client APIs use consistent hashing algorithms to determine which server to store and retrieve values for a particular key. The consistent hashing strategy allows for an even distribution of key-value pairs according to the memory allocated to each server in the pool, even when a server is added to or removed from the pool.
Each key-value pair is stored only in one location: there is no duplication across servers. This virtual architecture enables Memcached to be configured either to share memory with other processes across multiple servers, or consolidated to one or more dedicated Memcached servers. Memcached servers in a Memcached memory pool are unaware of each other. The servers track which data in their local array was least-recently used, and will purge that data as needed to make room for newer requests (called an eviction).
Different keys are randomly mapped to servers in a pool, which can explain why, sometimes, one Memcached server can display different statistics from another. This does not necessarily mean that something is wrong; it simply means that Drupal is sending different keys to each server, which is how consistent hashing operates.
Sometimes, one Memcached instance will display a disproportionate number of evictions, while the other servers in the pool will not. Having a few evictions is not necessarily bad - it effectively means Memcached is getting rid of old objects to make space for new ones. A website which is constantly churning one cache object (the cache of variables, for example) can put load on just one of its Memcached servers. The number of evictions can also be influenced by both the size and the volume (based on how the slabs in memory are being used) of objects being sent to that particular server.
If the amount of evictions seems to be causing issues, there are two main approaches to take:
- Send less to Memcached
Begin by analyzing what Drupal is sending to Memcached; it's not uncommon for excessive cache sets to be a symptom of a problem in Drupal that should be fixed.
One of the best methods to determine what a website is sending to Memcached is by intercepting the network traffic. To do this, you can use the
ngrepcommand, similar to the following:
sudo ngrep -w get -d lo port 11211 interface: lo (127.0.0.0/255.0.0.0) filter: (ip or ip6) and ( port 11211 ) match: ((^get\W)|(\Wget$)|(\Wget\W)) #### T 10.44.77.98:38467 -> 10.44.77.98:11211 [AP] get hecomstg_-cache_bootstrap-variables.. ########## T 10.44.77.98:38467 -> 10.44.77.98:11211 [AP] get hecomstg_-cache_bootstrap-bootstrap_modules.. ## T 10.44.77.98:38467 -> 10.44.77.98:11211 [AP] get hecomstg_-cache_bootstrap-lookup_cache.. ## T 10.44.77.98:38467 -> 10.44.77.98:11211 [AP] get hecomstg_-cache_bootstrap-system_list.. ##### T 10.44.77.98:38467 -> 10.44.77.98:11211 [AP] get hecomstg_-cache_bootstrap-module_implements..
You can also make a digest report from your tcpdump data using commands similar to this example:
sudo tcpdump -s 65535 -x -n -q -tttt -i lo port 11211 > /mnt/tmp/memc_tcpdump.txt mk-query-digest --type memcached /mnt/tmp/memc_tcpdump.txt > /mnt/tmp/memc_digest.txt
This digest is useful for debugging memcache issues. A specific place where it is useful is finding why a cache set operation failed.
If you intend to use
tcpdump, it is important to do the following:
- If you're an Acquia Cloud customer:
- Contact Acquia Support to let them know what you intend to do.
- Be sure that your dumpfile is in your
- Do not leave
tcpdumprunning for more than a few minutes. The dumpfile grows very fast for some customers
- If you're an Acquia Cloud customer:
- Allocate additional memory to Memcached
For information about how to do this on Acquia Cloud, see Using Memcached.
Pages, chunks, and slab classes
Memcache works with a PHP extension (PECL memcache ) that, in turn, interfaces with a background Memcached daemon.
The Memcached daemon divides the allocated memory into pages of a specified size. Each page contains chunks of a fixed size, each of which hold a key-value pair and some overhead memory. Any spare memory in a chunk cannot be used for anything else. If the chunk is too small, it won't be able to store the cached object. If it is too big, it will result in unused, wasted space.
To utilize memory more efficiently, Memcached allows different sized chunks, which are called slab classes. However, each page may hold only chunks of the same slab class. The largest slab class is 1MB. When Memcached stores a cached object, it looks for a page with the smallest slab class that will accommodate it.
Advanced Memcached configuration
Acquia customers should be aware of the following best practices when using Memcached:
- As with many other platform settings, Memcached can be configured by Acquia Cloud Professional customers. Acquia manages Memcached configuration for Acquia Cloud Enterprise customers.
- When modifying
settings.php, customers should not configure any Memcached attributes after the Acquia require line.
- We recommend that customers enable the Memcache API and Integration module, because it helps Acquia identify websites that have outdated versions of this module when new releases are deployed on drupal.org.
Memcached and multisite applications
Memcached can be used in multisite Drupal applications, which contain separate databases (one for each website) that share a common codebase and hardware. Acquia uses the name of the database as a Memcached prefix to logically separate the data. Acquia Cloud adds the correct
memcache_key_prefix value through Acquia-specific code in the website-specific
$conf['memcache_key_prefix'] = $conf['acquia_hosting_site_info']['db']['name'] . '_';
Customers should not modify the
memcache_key_prefix setting in
settings.php — setting a
memcache_key_prefix value manually can display unexpected behavior.
Dedicated Memcached servers
If your site experiences a growth in Memcached get/set times, Acquia recommends dedicated Memcached servers. For each Drupal bootstrap, a connection to each Memcached server must be made. Websites with heavy traffic should run no more than three to four instances of Memcached, as the connection overhead will cost more than the scalability gained by more instances.
Advantages of dedicated Memcached servers
- Dedicated Memcached servers decouple the performance of the caching layer from the PHP layer. Horizontal scaling of PHP servers will no longer cause increase an increase in Memcached get/set times.
- Dedicated Memcached servers also gives a bit or memory back to the webs meaning you may get an extra PHP processes on the webs giving you more concurrent processing capability.
- Dedicated Memcached servers can allocate much larger portions of memory to memcache. For example, the default allocation of memory to memcached on a web server is 64M. Depending on the instance type, dedicated servers will have between 3 and 12 Gigabytes of memory devoted to Memcached.
Disadvantages of dedicated Memcached servers
- Additional hardware is usually required for a dedicated Memcached server pair.
To determine whether moving to dedicated Memcached is the right decision, please file a support ticket.