Используем memcached для кэширования объектов и страниц wordpress

Redis против Memcached для кеширования данных

 Начнем со сходств. И Memcached, и Redis служат в качестве размещающихся в оперативной памяти хранилищ данных с ключом, хотя Redis более точно описывается как хранилище структуры данных. Как Memcached, так и Redis относятся к семейству решений для управления данными NoSQL, и оба они основаны на модели данных с ключевыми значениями. Они сохраняют все данные в ОЗУ (памяти), что, конечно же, делает их чрезвычайно полезными в качестве слоя кеширования. С точки зрения производительности два хранилища данных также очень похожи, демонстрируя почти идентичные характеристики (и показатели) в отношении пропускной способности и латентности.

Как Memcached, так и Redis являются зрелыми и чрезвычайно популярными проектами с открытым исходным кодом. Memcached был первоначально разработан Брэдом Фицпатриком в 2003 году на сайте LiveJournal. С тех пор Memcached был переписан на C (исходная реализация была в Perl) и помещена в общественное достояние, где она стала краеугольным камнем современных веб-приложений. Текущая разработка Memcached ориентирована на стабильность и оптимизацию, а не на добавление новых функций.

Redis был создан программистом Салваторе Санфилиппо (Salvatore Sanfilippo) в 2009 году, и он остается ведущим разработчиком проекта сегодня. Redis иногда описывается как «Memcached на стероидах», что неудивительно с учетом того, что части кода Redis были построены в ответ на уроки, извлеченные из использования Memcached. Redis имеет больше возможностей, чем Memcached, и, таким образом, более мощный и гибкий.

Используемые многими компаниями и в бесчисленных критически важных производственных средах, Memcached и Redis поддерживаются клиентскими библиотеками на всех мыслимых языках программирования и включаются в множество пакетов для разработчиков. Фактически, это редкий веб-стек, который не включает встроенную поддержку для Memcached или Redis.

Почему Memcached и Redis так популярны? Они не только чрезвычайно эффективны, но и относительно просты. Начало работы с Memcached или Redis считается простой работой для разработчика. Требуется всего несколько минут, чтобы настроить и заставить их работать с приложением. Таким образом, небольшая инвестиция времени и усилий может иметь непосредственное и внушительное влияние на производительность — обычно на порядок. Простое решение с огромной выгодой; это так близко к магии, которой вы можете с легкостью воспользоваться.

Установка Couchbase Server

В поле Hostname указываем private ip инстанса. Квоту по памяти я указал 10817 Мб из 16322 Мб доступных. Couchbase не позволяет использовать больше 80% от всей памяти в системе. Далее нам предложат создать тестовые наборы данных, отказываемся.

Затем создаем Memcached-бакет, скажем, размером 1 Гб

Обратите внимание, что это количество памяти будет выделено под бакет на каждой ноде. То есть, если у вас сейчас три ноды, всего под бакет в кластере будет выделено 3 Гб памяти

Если потом вы добавите еще ноду — то 4 Гб. Притом никого как бы не волнует, что ноды бывают немного разными. Учтите также, что квоту по памяти после создания можно изменить только у Couchbase бакетов, но не у Memcached бакетов!

Добавляем Memcached-бакет

Присоединяем вторую и третью ноду к кластеру. Заходим в админку аналогично тому, как делали это раньше. Теперь вместо «Start a new cluster» выбираем «Join a cluster now». После подключения всех нод идем во вкладку Server Nodes и жмем Rebalance.

Далее Settings → Auto-Failover → Enable auto-failover. Хорошим таймаутом, согласно документации, является 30 секунд. Если в вашем кластере раз в год ломается одна машина, с таким таймаутом вы получите «6 девяток», что должно быть за глаза практически любому проекту. Ставить таймаут меньше не имеет значения, так как вы получите те же «6 девяток», но с большей вероятностью ложного срабатывания автофейловера.

Установка таймаута

Собственно, это все, установка предельно проста! Развернуть и протестить кластер можно буквально за считанные минуты. Встроенный просмотр документов, метрики и мониторинг просто прекрасны, никаких Datadog’ов и Logentries’ов локально держать не нужно. Просто поставил и работает.

Очистить / очистить кеш DNS браузера

Большинство современных веб-браузеров имеют встроенный DNS-клиент для предотвращения повторяющихся запросов при каждом посещении веб-сайта.

Гугл Хром

Чтобы очистить кеш DNS Google Chrome , выполните следующие действия:

1. Откройте новую вкладку и введите в адресной строке Chrome.
2. Нажмите кнопку «Очистить кеш хоста».

Если это не сработает, попробуйте очистить кеш и файлы cookie.

1. Откройте диалоговое окно «Очистить данные просмотра» с помощью .
2. Выберите временной диапазон. Выберите «За все время», чтобы удалить все.
3. Установите флажки «Файлы cookie и другие данные сайта» и «Кэшированные изображения и файлы».
4. Нажмите кнопку «Очистить данные».

Этот метод должен работать для всех браузеров на базе Chrome, включая Chromium , Vivaldi и Opera .

Fire Fox

Чтобы очистить кеш DNS Firefox, выполните следующие действия:

1. В верхнем правом углу щелкните значок гамбургера чтобы открыть меню Firefox:
2. Щелкните .
3. Щелкните вкладку Конфиденциальность и безопасность или Конфиденциальность слева.
4. Прокрутите вниз до раздела « » и нажмите кнопку « .
5. Выберите временной диапазон для очистки. Выберите «Все», чтобы удалить все.
6. Установите все флажки и нажмите «Очистить сейчас».

Если это не сработает, попробуйте следующий метод и временно отключите кеш DNS.

1. Откройте новую вкладку и введите в адресной строке Firefox.
2. Найдите , временно установите значение 0 и нажмите OK. После этого верните значение по умолчанию и нажмите OK.
3. Найдите , временно установите значение 0 и нажмите OK. После этого верните значение по умолчанию и нажмите OK.

Развёртываем приложение и базы

Воспользуемся Docker. Нам нужно подготовить развёртывание трёх наших сервисов: MySQL, Redis и самого приложения.

Создадим Dockerfile для описания образа нашего приложения:

Затем создадим файл docker-compose (описывает несколько связанных между собой контейнеров):

В нашем случае файл содержит описание трёх сервисов с именами контейнеров, образов и обозначением портов. Параметром environment задаются переменные среды.

Настраиваем подключение к базе

Это делается в файле application.properties:

Обратите внимание, что в spring.datasource.url и spring.redis.host задаются хосты контейнеров. spring.cache.redis.time-to-live задаёт время существования параметра в кэше

spring.cache.redis.time-to-live задаёт время существования параметра в кэше.

Собираем проект

Это делается командами:

./mvnw clean package -Dmaven.test.skip=true — собираем проект в JAR-файл.

docker-compose up — инициируем выполнение файла docker-compose.yml — а именно сборку трёх образов и создание контейнеров.

Результат отразится в терминале:

Повторные запросы

Некоторые данные могут запрашиваться несколько раз в рамках одной страницы, например:

...
Email:
...
Моя страница
...

Каждый вызов get_user() будет получать данные из кэша. Если Memcache стоит на отдельном сервере, это вызовет большой сетевой трафик и задержки.Чтобы этого избежать, можно использовать дополнительный кэш внутри самого приложения:

memcache_connect('localhost', 11211);
function get_user($id)

{
global $app_cache;
if ( $app_cache ) return $app_cache;
if ( !$data = memcache_get('user' . $id) )

{
$sql = 'SELECT * FROM users WHERE id= ' . intval($id);
$q = mysql_query($sql);
$data = mysql_fetch_assoc($q);
memcache_set('user' . $id, $data, 60*60);
$app_cache = $data;

}
return $data;
}

function save_user($id, $data)
{
global $app_cache;
mysql_query('UPDATE users SET ... WHERE id = ' . intval($id));
memcache_delete('user' . $id);
unset($app_cache);
}

В реальных приложениях, имеет смысл иметь обертку для Memcache с дополнительным кэшом:

$data = memcache_get( $this->resource, $key );
$this->inner_cache = $data;
return $data;

}
public static function set( $key, $value, $ttl )
{
memcache_set($key, $value, $ttl);
$this->inner_cache = $value;
}

public static function del( $key )

{
memcache_delete($key);
unset($this->inner_cache);
}

}

$inner_cache хранит дополнительный кэш

Внимание. Использование этого подхода может приводить к утечкам памяти в случаях, когда идет работа с большим количеством данных в кэше

Например, в cron-задачах (допустим, мы перебираем всех пользователей для отправки рассылки). Тогда лучше добавить отключение внутреннего кэша:

$data = memcache_get( $this->resource, $key );
$this->inner_cache = $data;
return $data;

}
public static function set( $key, $value, $ttl )
{

memcache_set($key, $value, $ttl);
if ( self::$inner_cache_enabled ) $this->inner_cache = $value;

}
public static function del( $key )
{

memcache_delete($key);
unset($this->inner_cache);
}
}

...
mem_cache::$inner_cache_enabled = false;

Отключаем внутренний кэш

Ускорение WordPress за счет кеширования в memcached с помощью плагина W3 Total Cache

Май 22nd, 2015 Evgeniy Kamenev

    Установка memcached ранее рассматривалась Установка memcached в Ubuntu Установка memcached в Centos   1.Установка плагина w3 total cache через менеджер плагинов   2.Проверка/добавление наличие строки подключения плагина в файле wp-config.php

# cat -n /path_to_site/wp-config.php | less

1	# cat -n /path_to_site/wp-config.php | less

1 <?php
2 /** Enable W3 Total Cache */
3 define(‘WP_CACHE’, true); // Added by W3 Total Cache
4
5 /**

1 2 3 4 5

1<?php 2/** Enable W3 Total Cache */ 3define(‘WP_CACHE’,true);// Added by W3 Total Cache 4 5**

3.Настройка Nginx виртуального хоста(включаем сжатие и определяем типы файлов для сжатия ) в http-секции

# nano /etc/nginx/conf.d/virtualhostname.conf

1	# nano /etc/nginx/conf.d/virtualhostname.conf

server {
……….
include /path_to_site/nginx.conf;
}

1 2 3 4

server{ ………. includepath_to_sitenginx.conf; }

Проверка наличия файла nginx.conf в

Опубликовано в рубрике Nginx, Web, Web, Web Метки: memcached, Nginx, w3 total cache, wordpress Комментарии к записи Ускорение WordPress за счет кеширования в memcached с помощью плагина W3 Total Cache отключены

Работа с memcached в Unix/Linux

Приведу наглядные примеры по работе с memcached.

Получить ( Показать) статус memcached.

Получить статистику:

# echo stats | nc 127.0.0.1 11211


STAT pid 1250
STAT uptime 5099765
STAT time 1483695061
STAT version 1.4.22
STAT libevent 1.4.13-stable
STAT pointer_size 64
STAT rusage_user 3144.195009
STAT rusage_system 15863.643359
STAT curr_connections 15
STAT total_connections 14347484
STAT connection_structures 908
STAT reserved_fds 30
STAT cmd_get 424027417
STAT cmd_set 16380427
STAT cmd_flush 20
STAT cmd_touch 0
STAT get_hits 212115737
STAT get_misses 211911680
STAT delete_misses 259355
STAT delete_hits 3729812
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 93778486542
STAT bytes_written 2478939093660
STAT limit_maxbytes 4294967296
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 6
STAT conn_yields 0
STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT malloc_fails 0
STAT bytes 18891891
STAT curr_items 4120
STAT total_items 16380427
STAT expired_unfetched 0
STAT evicted_unfetched 0
STAT evictions 0
STAT reclaimed 170726
STAT crawler_reclaimed 0
STAT lrutail_reflocked 79
END

Вот простой «top» эмулятор для memcached:

# watch "echo stats | nc 127.0.0.1 11211"

PS: Я использую локальную машину ( локалхост, 127.0.0.1), если вы хотите подключатся к удаленной машине, то замените  ИП. Так же, не забываем сменить порт ( если настроили по другому).

Если вы хотите просмотреть подробную информацию об использовании кэша найти конкретный ключ, вы можете использовать одну из следующих команд:

• stats items — показывает информацию о количестве элементов в каждой плите (slab) со включающей нумерацией времени ( элементы, которые были очищены, прежде чем они истекли (inserted) или элементы не смогли быть вставлены потому, что slab вышел за пределы памяти (out of memory):
  Для начала подключимся:

  # telnet 127.0.0.1 11211

  После чего смотрим статистику:

  > stats items
  
  STAT items:1:number 2
  STAT items:1:age 526034
  STAT items:1:evicted 0
  STAT items:1:outofmemory 0

  Или:

  # echo stats items | nc 127.0.0.1 11211

• stats slabs — покажет более детальную статистику по каждому slab, такие как количество страниц (которые были выделены) и процент имеющихся кусков, которые используются:

  > stats slabs
  
  STAT 5:chunk_size 240
  STAT 5:chunks_per_page 4369
  STAT 5:total_pages 1
  STAT 5:total_chunks 4369
  STAT 5:used_chunks 7
  STAT 5:free_chunks 1
  STAT 5:free_chunks_end 4361

  Или:

  # echo stats slabs | nc 127.0.0.1 11211

• Если вы заинтересованы в просмотре отдельных ключей, которые хранятся на сервере, вы можете использовать команду — stats cachedump  чтобы получить список ключей в каждой плите (slab). Команда принимает два аргумента: идентификатор slab и количество элементов для извлечения (0 = извлечь все):

  > stats cachedump 6 3
  
  ITEM cache_menu-links%3Asecondary-links 
  ITEM cache_menu-links%3Aprimary-links 
  ITEM cache_menu-links%3Anavigation 

Для просмотра item-ов:
# echo stats items | nc 127.0.0.1 11211

Для тех у кого нет nc, но есть php:

# watch 'php -r '"'"'$m=new Memcache;$m->connect("127.0.0.1", 11211);print_r($m->getstats());'"'"

Как-то так.

Очистить ( сбросить) memcached кеш

Вы можете очистить все существующие элементы кэша с помощью команды flush_all. Вы можете отправить flush_all команду, используя  nc или netcat утилиты:

# echo 'flush_all' | nc localhost 11211

Или можно еще одним способом:

# echo 'flush_all' | netcat localhost 11211

Вот еще пример:

# nc 192.168.1.10 11211<<<"flush_all"

Где,

• 192.168.1.10 или localhost– сервер где установлен memcached
• 11211 – порт который использует memcached.

Сейчас я расскажу как можно сбросить кэш с помощью telnet:

# telnet Your_Server_or_IP Your_Memcached_Port

Пример:

$ telnet 192.168.13.113 11211

Статья «Работа с memcached  в Unix/Linux» завершена.

Справочная архитектура

На приведенной ниже схеме архитектуры показана среда memcached до и после того, как уровень кэширования заменен сервером Couchbase.

Memcached архитектура против Couchbase Server

Один из вариантов использования Couchbase Server — функционировать как слой кэширования в типичной веб-архитектуре, как показано выше. Низкая латентность, согласованная производительность и линейная масштабируемость Couchbase Server делают ее подходящей заменой уровня memcache; его встроенная технология кеширования обеспечивает время ответа в миллисекундах, соответствующее времени memcached.

Данные в Couchbase Server автоматически разбиваются на разделы и распределяются между узлами кластера. Каждый узел кластера Couchbase идентичен, и данные реплицируются по узлам, так что каждый узел хранит как активные, так и реплики документов. Клиенты Couchbase имеют топологию и автоматически направляют запросы непосредственно на соответствующий узел.

Кроме того, консоль администратора в Couchbase Server позволяет отслеживать и управлять на уровне кластера (а не на уровне сервера, как и с memcached), упрощая управление и операции системы и экономя ваше время.

Алгоритмы кэширования

Алгоритмы кэширования — это подробный список инструкций, который указывает, какие элементы следует отбрасывать в кэш. Их еще называют алгоритмами вытеснения или политиками вытеснения.

Когда кэш заполнен, алгоритм должен выбрать, какую именно запись следует из него удалить, чтобы записать новую, более актуальную информацию.

Least recently used — LRU (Вытеснение давно неиспользуемых)

LRU — это алгоритм, при котором вытесняются элементы, которые дольше всего не запрашивались. Соответственно, необходимо хранить время последнего запроса к элементу. И как только кэш становится заполненным, необходимо вытеснить из него элемент, который дольше всего не запрашивался.

Общая реализация этого алгоритма требует сохранения «бита возраста» для элемента и за счет этого происходит отслеживание наименее используемых элементов. В подобной реализации, при каждом обращении к элементу меняется его «возраст».

LRU на самом деле является семейством алгоритмов кэширования, в которое входит 2Q, а также LRU/K.

Для реализации понадобятся две структуры данных:

• Хеш-таблица, которая будет хранить закэшированные значения.
• Очередь, которая будет хранить приоритеты элементов и выполнять следующие операции:
  • Добавить пару значение и приоритет.
  • Извлечь (удалить и вернуть) значение с наименьшим приоритетом.

Пошаговый алгоритм:

• Проверяем, есть ли значение в кэше:
  • Если значение уже есть, то обновляем время последнего к нему запроса и возвращаем значение.
  • Если значения нет в кэше — вычисляем его.
• Проверяем размер кэша:
• Добавляем значение в хеш-таблицу и в очередь.

Достоинства:

константное время выполнения и использование памяти.

Недостатки:

алгоритм не учитывает ситуации, когда к определенным элементам обращаются часто, но с периодом, превышающим размер кэша (т.е. элемент успевает покинуть кэш).

Псевдо-LRU — PLRU

PLRU — это алгоритм, который улучшает производительность LRU тем, что использует приблизительный возраст, вместо поддержания точного возраста каждого элемента.

Most Recently Used — MRU (Наиболее недавно использовавшийся)

MRU — алгоритм, который удаляет самые последние использованные элементы в первую очередь. Он наиболее полезен в случаях, когда чем старше элемент, тем больше обращений к нему происходит.

Least-Frequently Used — LFU (Наименее часто используемый)

LFU — алгоритм, который подсчитывает частоту использования каждого элемента и удаляет те, к которым обращаются реже всего.

В LFU каждому элементу присваивается — счётчик. При повторном обращении к элементу его счётчик увеличивается на единицу. Таким образом, когда кэш заполняется, необходимо найти элемент с наименьшим счётчиком и заменить его новым элементом. Если же все элементы в кэше имеют одинаковый счётчик, то в этом случае вытеснение осуществляется по методу FIFO: первым вошёл — первым вышел.

Недостатки:

• много обращений к элементу за короткое время накручивает счётчик и в результате элемент зависает в кэше.
• алгоритм не учитывает “возраст” элементов.

Multi queue — MQ (Алгоритм многопоточного кэширования)

MQ — алгоритм, использующий несколько LRU очередей — Q0, Q1, …, Qn, между которыми элементы ранжируются/перемещаются в зависимости от частоты обращения к ним.

В дополнение к очередям используется буфер “истории” — Q_out, где хранятся все идентификаторы элементов со счётчиками (частота обращения к элементу). При заполнении Q_out удаляется самый старый элемент.

Элементы остаются в LRU очередях в течение заданного времени жизни, которое динамически определяется специальным алгоритмом.

Если к очереди не ссылались в течение её времени жизни, то её приоритет понижается с Qi до Qi-1 или удаляется из кэша, если приоритет равен 0 — Q0.

Каждая очередь также имеет максимальное количество обращений к её элементам. Поэтому если к элементу в очереди Qi обращаются более 2i раз, то этот элемент перемещается в очередь Qi+1.

При заполнении кэша, будет вытеснен элемент из очереди Q0, который дольше всех не использовался.

Картинка для наглядности:

Другие алгоритмы

Алгоритмов кэширования достаточно много, поэтому на данный момент не все здесь рассмотрены. С полным списком можно ознакомиться здесь.

Со временем буду дополнять.

Как освободить кэш память в Linux

В каждом дистрибутиве Linux можно использовать три команды чтобы очистить кэш памяти linux. Причем вам не придется завершать никаких процессов. Сначала войдите в консоль от имени суперпользователя:

Затем выполните одну из команд. Очистка кэша PageCache:

Очистка inode и dentrie:

Очистка inode и dentrie и PageCache:

А теперь давайте рассмотрим что происходит при выполнении этих команд.

Утилита sync заставляет систему записать все кэшированные, но еще не записанные данные на диск. Это нужно чтобы освободить как можно больше памяти. По умолчанию данные после записи на диск не удаляются из кэша, это нужно для того, чтобы программа могла быстрее их считать при необходимости.

Если не выполнить команду sync мы тоже освободим немного места, но после ее выполнения результат будет лучше.

Символ разделения ; дает знать оболочке, что перед тем как выполнить другую команду, нужно дождаться завершения работы первой. Последняя команда echo 1 > /proc/sys/vm/drop_caches записывает значение 1 в файл /proc/sys/vm/drop_caches. Это дает сигнал ядру, что нужно очистить выбранный нами вид кэша.

Виды кэша в Linux

А теперь давайте рассмотрим виды кэша, которые позволяют очищать эти команды, а также как все это работает.

PageCache или страничный кэш — это место, куда ядро складывает все данные, которые вы записывали или читали из диска. Это очень сильно ускоряет работу системы, так как если программе во второй раз понадобятся те же данные, они просто будут взяты из оперативной памяти. Но по этой причине этот кэш занимает больше всего места.

Посмотреть размер страничного кэша можно с помощью утилиты free. Здесь он показан в последней колонке — cached:

Такой кэш чистить эффективнее и безопаснее всего.

Кэш inode и dentrie тоже относится к файловой системе. Только в него записываются не сами данные, а структура файловой системы, расположение файлов и папок. При запросе расположения файла или содержимого папки ядро формирует специальные структуры, в которых есть вся эта информация. При следующем запросе структуры будут уже сохранены в памяти. Для каждой файловой системы существует свой кэш inode и общий кэш dentrie.

Этот кэш занимает очень мало памяти. Данные представлены в байтах, и как видите, это очень мало. Посмотреть его можно командой:

Очищать его чтобы освободить память linux не рекомендуется, так как памяти потребляется немного, а на новое сканирование файловой системы идет относительно много времени.

Нужно ли очищать кэш вообще?

Во-первых, если занято очень много памяти, вы можете очистить страничный кэш, особенно если это он занимает много памяти. Во-вторых, очистить кэш памяти linux может понадобиться, если вы изменяли какие-либо настройки файловой системы или ядра, а теперь хотите проверить как это отразилось на скорости операций чтения/записи. В таком случае можно очистить все кэши и сделать это без перезагрузки, что очень удобно.

Операционная система Linux разработана таким образом, что перед тем как обратиться к диску, будет просмотрен кэш диска, и если там есть нужные данные, к диску обращений не будет. Если очистить кэш Linux то операционная система будет работать немного медленнее, поскольку ей придется искать данные на диске.

Автоматическая очистка кэша

Давайте рассмотрим как автоматически очистить кэш памяти ежедневно в два часа ночи с помощью планировщика заданий cron.

Сначала создадим bash скрипт со следующим содержимым:

Очищать будем только страничный кэш, так как он занимает больше всего. Другие виды трогать не будем, чтобы зря не понижать производительность системы.

Дальше сделайте скрипт исполняемым:

Осталось добавить задание в планировщик cron. Для этого выполните команду:

И в открывшемся редакторе добавьте строчку:

Теперь этот скрипт будет выполняться каждую ночь и выполнять очистку памяти, чтобы сервер мог работать нормально.

Options

-s <file>

Unix socket path to listen on (disables network support).

-a <perms>

Permissions (in octal format) for Unix socket created with -s option.

-l <ip_addr>

Listen on <ip_addr>; default to INADDR_ANY. This is an important option to consider as there is no other way to secure the installation. Binding to
an internal or firewalled network interface is suggested.

-d

Run memcached as a daemon.

-u <username>

Assume the identity of <username> (only when run as root).

-m <num>

Use <num> MB memory max to use for object storage; the default is 64 megabytes.

-c <num>

Use <num> max simultaneous connections; the default is 1024.

-R <num>

This option seeks to prevent client starvation by setting a limit to the number of sequential requests the server will process from an individual client
connection. Once a connection has exceeded this value, the server will attempt to process I/O on other connections before handling any further request from
this connection. The default value for this option is 20.

-k

Lock down all paged memory. This is a somewhat dangerous option with large caches, so consult the README and memcached homepage for configuration
suggestions.

-p <num>

Listen on TCP port <num>, the default is port 11211.

-U <num>

Listen on UDP port <num>, the default is port 11211, 0 is off.

-M

Disable automatic removal of items from the cache when out of memory. Additions will not be possible until adequate space is freed up.

-r

Raise the core file size limit to the maximum allowable.

-f <factor>

Use <factor> as the multiplier for computing the sizes of memory chunks that items are stored in. A lower value may result in less wasted memory
depending on the total amount of memory available and the distribution of item sizes. The default is 1.25.

-n <size>

Allocate a minimum of <size> bytes for the item key, value, and flags. The default is 48. If you have a lot of small keys and values, you can get a
significant memory efficiency gain with a lower value. If you use a high chunk growth factor (-f option), on the other hand, you may want to increase the size
to allow a bigger percentage of your items to fit in the most densely packed (smallest) chunks.

-C

Disable the use of CAS (and reduce the per-item size by 8 bytes).

-h

Show the version of memcached and a summary of options.

-v

Be verbose during the event loop; print out errors and warnings.

-vv

Be even more verbose; same as -v but also print client commands and responses.

-i

Print memcached and libevent licenses.

-P <filename>

Print pidfile to <filename>, only used under -d option.

-t <threads>

Number of threads to use to process incoming requests. This option is only meaningful if memcached was compiled with thread support enabled. It is
typically not useful to set this higher than the number of CPU cores on the memcached server. The default is 4.

-D <char>

Use <char> as the delimiter between key prefixes and IDs. This is used for per-prefix stats reporting. The default is «:» (colon). If this option is
specified, stats collection is turned on automatically; if not, then it may be turned on by sending the «stats detail on» command to the server.

-L

Try to use large memory pages (if available). Increasing the memory page size could reduce the number of TLB misses and improve the performance. In order
to get large pages from the OS, memcached will allocate the total item-cache in one large chunk. Only available if supported on your OS.

-B <proto>

Specify the binding protocol to use. By default, the server will autonegotiate client connections. By using this option, you can specify the protocol
clients must speak. Possible options are «auto» (the default, autonegotiation behavior), «ascii» and «binary».

-I <size>

Override the default size of each slab page. Default is 1mb. Default is 1m, minimum is 1k, max is 128m. Adjusting this value changes the item size limit.
Beware that this also increases the number of slabs (use -v to view), and the overal memory usage of memcached.