Неожиданная (?) Высокая «потерянная» память в memcached


18

Обновлено, смотрите в нижней части длинного (извините) вопроса.

Глядя на нашу статистику memcached, я думаю, что нашел проблему, о которой раньше не знал. Кажется, что у нас странно много пустого места. Я проверил phpmemcacheadmin на предмет изменений и обнаружил, что это изображение смотрит на меня:

график размера кэша memcached

Теперь у меня сложилось впечатление, что в худшем случае будет 50% отходов, хотя я первый, кто признает, что не знает всех деталей. Я прочел, среди прочего, эту страницу, которая действительно несколько устарела, но также и наша версия memcached. Я думаю, что я понимаю, как работает система ( например ), я верю, но мне трудно понять, как мы можем получить до 76% потраченного впустую пространства.

Показатель выселения, который показывает phpmemcacheadmin 2 ev/s, так что здесь есть некоторая проблема.

  • Основной вопрос: что я могу сделать, чтобы это исправить . Я мог бы бросить больше памяти (есть некоторые дополнительные доступные, я думаю), возможно, я должен возиться с конфигом slab (это вообще возможно в этой версии?), Может быть есть другие варианты? Обновление версии memcached не является доступной опцией.

  • Второй любопытный вопрос, из любопытства, это, конечно, если ожидается, что будет потрачено 75% (и все больше) потерянного пространства, и если да, то почему.

Система: В настоящее время я ничего не могу с этим поделать, я знаю, что версия memcached не самая новая, но это карты, которые мне сдали.

  • Memcached 1.4.5
  • Apache 2.2.17
  • PHP 5.3.5

В ответ на ответ @DavidSchwartz: вот статистика по слябам, которую генерирует phpmemcacheadmin: (кстати, есть больше слябов, чем эти)

( Я также вставил статистику чуть позже в текстовом формате здесь )

Детали плиты

ОБНОВИТЬ

Я перезапустил демон с -f 1.5, и он выглядел очень хорошо. После некоторого потепления у нас было потрачено впустую 50/50. Но, так же, как и раньше, чем дольше мы были в течение дня (он становится более занятым в течение дня), он начал возвращаться к тому, что он в настоящее время: 30/70, и потери растут. Кроме того, я до сих пор не знаю, откуда приходит «впустую». Я вижу эту плиту:

**Slab 5 Stats**
Chunk Size  496.0 Bytes
Used Chunk  77502 [24.6 %]
Total Chunk 314986
Total Page  149
Wasted      117.3 MBytes
Hits        30.9 Request/sec
Evicted     0

Он не заполнен, его не выселили, но он тратит 117,3 МБ. Быстрый расчет, который я сделал (поправьте меня, если я ошибаюсь) был:

  • предыдущий кусок имеет размер фрагмента 328, поэтому в худшем случае этот фрагмент заполнен фрагментами 329 байт.
  • это означает, что он тратит 167 байт на использованный блок = 12942834 байт = 12,3 МБ

Так откуда же взялись остальные потраченные 105 МБ ? Рядом со старшим братом это выглядит так:

**Slab 6 Stats** 
Chunk Size  744.0 Bytes
Used Chunk  17488 [31.0 %]
Total Chunk 56360
Total Page  40
Wasted      31.1 MBytes
Hits        107.7 Request/sec
Evicted     1109

Проблема в том, что в других плитах есть тонны неиспользуемого пространства, но плита 3 заполнена на 100% и выселена.
Дэвид Шварц

Хороший момент, который объяснил бы выселения, хотя я не совсем уверен, как рассчитывается «потраченное впустую» число. Если для плиты 8 используется только 13,9%, то наверняка там должно быть какое-то «свободное» пространство?
Нанн

Да, в этой плите есть свободное место. Но это не поможет, если объекты, которые выселяются, не попадают в эту плиту.
Дэвид Шварц

Вот что я понял из вашего ответа, но почему в списке нет свободного места? Там должна быть какая-то часть этой круговой диаграммы белого цвета (как это делается на моей тестовой установке), если осталось место, по крайней мере, это то, что я понял
Nanne

Ответы:


10

Прошел год с тех пор, как этот вопрос, и я не знаю, нашли ли вы свой ответ, но я скажу, что ваше восприятие «впустую» неверно.

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

Для упрощения объяснения предположим, что у вас есть memcache с 3 МБ оперативной памяти с 3 Slabs:

slab class  1: chunk size     10485 perslab      100
slab class  2: chunk size    104857 perslab       10
slab class  3: chunk size   1048576 perslab        1

Выполните один «набор» размером 10К. Вы увидите в своей статистике (примерно), что у вас есть:

0.03% used
66.6% free
33% wasted

Это связано с тем, что memcached выделил один кусок из "класса 1 плиты", и 99% памяти для этой плиты "потеряно", а 1% "использовано". Это не означает, что плита и память, выделенная для этой плиты, исчезли.

Выполните еще один "набор" размером 10 КБ. На этот раз вы увидите:

0.06% used
66.6% free
32.7% wasted

так что теперь вы используете 2 из 100 выделенных блоков в slab 1, статистика «потраченных впустую» отброшена, а используемая статистика увеличилась.

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

Чтобы увидеть эту проблему "набор" с размером 100 КБ и еще один с размером 1000 КБ

Теперь вы увидите

36.6% used
   0% free
63.3% wasted

Это звучит неплохо! У вас есть какая-нибудь ссылка, чтобы подтвердить это? Если это так, значит мой memcache-сервер работал (работает) лучше, чем мы думаем :). Если я правильно вас понимаю, то, что впустую означает, что он был выделен, но все еще доступен для использования. Это означает, что если ничего не свободно, вы не можете выделить больше плит, но не должно ли это означать, что у вас есть проблема как таковая?
Нанн

1
У меня нет ссылки сверху моей головы, но это очень легко проверить себя. Нажмите на командную строку и создайте небольшой пример сервера, чтобы проверить, как он работает. Вы можете использовать опцию -vv для подробных отладочных сообщений, которые покажут вам изначально созданные плиты, например: "memcached -vv -p 11500 -m 3 -n 10000 -f 10" создаст вам 3 плиты с размерами фрагментов 10k, 100k и 1000k. И продолжайте выпускать "наборы" и смотрите, как меняется статистика потраченных впустую / использованных ресурсов, как я описал выше
Кали

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

6

У вас, наверное, очень большое количество очень маленьких предметов. Как правило, наименьшая плита содержит 104-байтовые записи. Если у вас есть много записей, которые просто отображают одно целое число в другое, вы можете получить отходы до 85%.

Вы можете найти информацию о том, как это настроить, в статье Memcached для небольших объектов .


Если я правильно прочитал страницу статистики, это не так. Большая часть отходов находится в слое с 480.0 байт-кусками. Позвольте мне проверить, могу ли я показать некоторые статистические данные ...
Nanne

О, тогда это нормально и нормально, не о чем беспокоиться. Там сейчас просто меньше данных. (Обратите внимание, например, что эта плита используется только на 14%.)
Дэвид Шварц

Но как 75% потрачено нормально? Включает ли это число неиспользуемое пространство? Я ожидаю, что это будет считаться «бесплатным». Кроме того, мы видим увеличение потраченной впустую // уменьшения используемой памяти с течением дня, когда сайт становится более загруженным. Это и тот факт, что у нас есть выселения, заставляют меня задуматься, что можно сделать.
Нанн

Наличие меньшего количества пластин может помочь избежать проблемы слишком большого количества памяти, застрявшей в неправильной пластине. Например, -f 1.5 -I 2800может помочь.
Дэвид Шварц

Страница руководства не слишком понятна: -I 2800что означает 2800K, а не 1M по умолчанию?
Нанн

-1

У меня была эта проблема, и я перешел из memcached в redis (без сохранения на диск). Я знаю, что это может быть невозможно, но вы могли бы попробовать это как вариант и следить за фрагментацией памяти. Вы можете даже включить постоянство, чтобы исправить проблемы «старого кэша» при перезапуске.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.