Cloud Platform
Memcached and Acquia hosting
Acquia’s Memcached solution is comprised of the following four major pieces: The Memcached daemon, the PHP Memcached library, the Memcache API and Integration module, and Drupal core.
For introductory information about Memcached, see Using Memcached. For instructions on how to enable Memcached, see Enabling Memcached on Acquia Cloud.
For non-FedRAMP customers:
The Memcached daemon is installed as a service with several components that work together to ensure stability and uptime for a website.
Memcached is a key-value store, which is a data storage paradigm designed for storing, retrieving, and managing associative arrays—commonly known as a hash. This contrasts with relational database object models that enable advanced concepts such as mapping and data types.
The Memcached service includes the following commands for handling data:
Cloud Platformget - Retrieve an existing item from storage.set - Save a new item to storage.flush_all - Mark an item as expired so that it cannot be retrieved. This method pushes the current item to the front of the line, to be replaced by the next cacheable item. It does not free the memory used by that item.delete - Remove an item from storage.stats - Query the service for aggregated data about the objects saved to storage.When the Memcached service is started, it reserves memory for object storage (by default, 64 MB). The memory allocated is divided into 1MB pages, which by default provides 64 pages. Memcached initializes a memory organization concept called a slab class on startup. A slab defines the number of items (chunks) which can be inserted into a 1MB memory page. By dividing 1MB by that number of chunks, you can determine that slab’s chunk size.
By default, Memcached creates 42 slabs and assigns a single page to each. Each successive slab holds fewer, larger chunks based on the factor (by default, 1.25). In the following sample representation of slabs, notice that the item size (or chunk size) increases by a factor of 1.25 from the second to the third slab:
# Item_Size Max_age Pages Count Full? Evicted Evict_Time OOM
2 120B 1168824s 1 170 no 0 0 0
3 152B 1831103s 1 196 no 0 0 0
4 192B 1847211s 1 988 yes 30 9183 0
...
36 246.8K 27236s 6 21 yes 7 2676 0
37 308.5K 1224s 2 3 yes 91 29174 0
...
40 602.5K 1696s 11 4 yes 0 0 0
41 753.1K 64s 4 1 yes 6 35 0
42 1024.0K 44944s 5 1 yes 20 1 20Memcached saves items by evaluating an item’s size, and then writing it to a slab. In the previous example, note that slab 36 contains items that range in size from 246.8KB to less than 308.5KB.
When a slab cannot fit a new item and there is additional memory available to Memcached, a new page will be assigned to the slab. In the previous example, slab 36 can contain at most four items, but, depending on the items’ size, may contain only three items:
When the set() method is called, Memcached determines the size of the object, and then locates the slab with the appropriate memory allocation.
Each Memcached node is configured to manage its memory with Least Recently Used (LRU) prioritization. The nodes oversee their local slab arrays, producing a list of candidates for removal. When a new item is assigned to a full slab and there are no free pages to assign to that slab, the full slab evicts the LRU item from the same slab. This is both healthy and accepted behavior—assuming that the objects being evicted are outdated and due to be safely removed.
Memcached does not internally provide mechanisms for adding capacity through additional processes. Instead, this functionality is handled entirely by an external client, such as the PECL Memcache extension for PHP.
An item cached by Memcached is stored in a specific location on a single infrastructure, even if your subscription includes multiple Memcached infrastructure.
If a Memcached infrastructure fails, its cached items will no longer be available, and requests for these items will be rerouted to the database layer of your application. Memcached cannot detect failed infrastructure, and will continue to route requests to all infrastructure, resulting in slow or failed requests until the failed infrastructure is repaired or removed from service. Although healthy Memcached infrastructure in your subscription will continue to respond normally, responses may slow or fail if the data source becomes overloaded.
If Memcached must be restarted on a single node, all Memcached nodes for that cluster must be reset. If this doesn’t occur, multi_item objects contain incomplete data.
You can enable Memcached for a site hosted on Cloud Platform by following the steps mentioned on Enabling Memcached on Cloud Platform. After you complete those steps, the system configures your website to use Memcached for most of the Drupal cache bins, except the following:
The preceding bins use a ChainedFast Cache backend that couples an inconsistent, fast, and local cache (APCu) with a distributed and consistent Memcache backend.
When using Memcache, some of the Cache bins that use Memcached as the backend include:
For advanced information about cache bins, see the configuration section of the Drupal Cache API documentation on Drupal.org.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
When the set() method is called, Memcached determines the size of the object, and then locates the slab with the appropriate memory allocation.
Each Memcached node is configured to manage its memory with Least Recently Used (LRU) prioritization. The nodes oversee their local slab arrays, producing a list of candidates for removal. When a new item is assigned to a full slab and there are no free pages to assign to that slab, the full slab evicts the LRU item from the same slab. This is both healthy and accepted behavior—assuming that the objects being evicted are outdated and due to be safely removed.
Memcached does not internally provide mechanisms for adding capacity through additional processes. Instead, this functionality is handled entirely by an external client, such as the PECL Memcache extension for PHP.
An item cached by Memcached is stored in a specific location on a single infrastructure, even if your subscription includes multiple Memcached infrastructure.
If a Memcached infrastructure fails, its cached items will no longer be available, and requests for these items will be rerouted to the database layer of your application. Memcached cannot detect failed infrastructure, and will continue to route requests to all infrastructure, resulting in slow or failed requests until the failed infrastructure is repaired or removed from service. Although healthy Memcached infrastructure in your subscription will continue to respond normally, responses may slow or fail if the data source becomes overloaded.
If Memcached must be restarted on a single node, all Memcached nodes for that cluster must be reset. If this doesn’t occur, multi_item objects contain incomplete data.
You can enable Memcached for a site hosted on Cloud Platform by following the steps mentioned on Enabling Memcached on Cloud Platform. After you complete those steps, the system configures your website to use Memcached for most of the Drupal cache bins, except the following:
The preceding bins use a ChainedFast Cache backend that couples an inconsistent, fast, and local cache (APCu) with a distributed and consistent Memcache backend.
When using Memcache, some of the Cache bins that use Memcached as the backend include:
For advanced information about cache bins, see the configuration section of the Drupal Cache API documentation on Drupal.org.
If this content did not answer your questions, try searching or contacting our support team for further assistance.