Почему APC увеличивает «Cache full count» для User Cache, хотя у него достаточно свободной памяти? - PullRequest
11 голосов
/ 28 июля 2010

Я играл с этим довольно долго, но немного растерялся относительно того, что делать.Я использую APC 3.1.3p1 на CentOs 5 с PHP 5.2.5.APC действует как кэш кода операции и кэш пользователя.В основном этот сервер работает на сайтах Drupal 6, использующих модуль CacheRouter для поддержки кэширования APC.Некоторое время я запускал APC 3.0.19, но это иногда приводило к блокировке Apache (задокументированная ошибка в этой версии APC), поэтому я нахожусь на 3.1.3p1.

Я настроилУ APC 512 МБ памяти (mmap).

Симптомы немного перемежаются, но, начиная с пустого кэша, обычно это то, что я вижу:

  • Пользователькеш заполняется довольно медленно.Несмотря на начальную скорость вставки около 20 000 вставок в секунду, пользовательский кеш будет сообщать только о нескольких сотнях, затем о нескольких тысячах записей, и будет расти очень медленно.Я могу приписать это включенной функции write_locking, но просто хочу упомянуть об этом на случай, если это важно для решения проблемы.Через несколько часов он достигает равновесия около 30 000 записей.

  • Фрагментация наступает рано и быстро растет.В течение примерно 10 часов или около того я обычно на 100% фрагментирую.

  • Общее использование кэша (код операции + пользователь) стабилизируется на уровне около 240 МБ или около того.Он практически никогда не поднимется выше этого уровня.Примерно через день я начну наблюдать увеличение полного счета кэша пользователей (UCCFC).

На момент написания этой статьи мой UCCFC был на уровне 62358 и продолжает расти, несмотря на то, что APC сообщает о свободном объеме 280 МБ.У меня user_ttl 7200, но я также поиграл с установкой его в 0 или другими значениями, и это мало влияет на проблему.

Я подозреваю, что проблема связана с фрагментацией.Прямо сейчас мой сервер сообщает: «Фрагментация: 100,00% (280,0 МБ из 280,0 МБ в 24740 фрагментах)» и 280 МБ - именно столько свободного пространства сообщает APC;Я думаю, что это совпадение.К сожалению, я нашел очень мало информации в документах или где-либо еще, чтобы указать, что на самом деле означает «фрагментация» в мире APC, и, кажется, вы практически ничего не можете сделать, чтобы избежать этого.

Может кто-нибудьпролить свет на эту проблему?

Ответы [ 2 ]

22 голосов
/ 07 августа 2010

APC вычисляет процент фрагментации, используя следующую формулу:

(total_size_of_free_blocks_lt_5M / total_size_of_all_free_blocks) * 100

* Обратите внимание, что он считает только блоки меньше 5M как фрагментированные.

Я будупереведите ваш конкретный случай на простой английский:

Фрагментация: 100,00% (280,0 МБ из 280,0 МБ в 24740 фрагментах)

Это означает, что из 280 МБ вашего бесплатногоблоки все из них менее 5М.Если вы поделите свободное пространство на количество фрагментов, вы увидите, что это соответствует среднему размеру фрагмента ~ 11,6K.

Это означает, что если вы попытаетесь сохранить элемент размером больше всех доступных блоков, он не поместится, и произойдет одно из двух, в зависимости от настройки конфигурации apc.user_ttl .Если TTL установлен в 0, то весь пользовательский кеш очищается и элемент вставляется.Если TTL установлен больше 0, он сбрасывает записи с истекшим сроком и вставляет элемент.В обоих случаях полный счет кеша увеличивается.Наличие такого приращения, как и в вашем случае, является показателем того, что вы, возможно, делаете это неправильно .

Вот простая визуализация того, что фрагментация делает с вашим кешем с течением времени.Он представляет собой простой 32-байтовый размер кэша, каждый блок 1B.

[--------------------------------] (starts empty)
[A-------------------------------] (1B stored)
[ABB-----------------------------] (2B stored)
[ABBCCCC-------------------------] (4B stored)
... (time elapses)
[A--CCCC-EEE--GGGGGG-III--KKKLLLL]

Так что теперь, если вы хотите сохранить элемент M, который имеет размер 4B, вы не можете, потому что самый большой доступный блокэто 2B.Это вызывает приращение полного кэша и полное или частичное очищение на основе user_ttl, подробно описанного выше.

Теперь вопрос: Это плохо в вашем случае?

Я думаю, что это может быть.100% фрагментация кеша сама по себе неплоха.Нередко это можно увидеть на любом работающем сервере.Тем не менее, на 100% с , когда много свободного места, это признак того, что что-то может быть не так.

  • Возможно, вы слишком много кешируете;просто потому, что там есть кеш, не означает, что вы должны вставить в него все
  • Возможно, вы кэшируете с слишком коротким TTL (для записи), низкие значения TTL означают, что несвободные блоки освобождаются чаще.
  • Также возможно, что у вас есть несколько действительно больших предметов, которые вы пытаетесь сохранить.При 100% фрагментации гарантируется, что любой элемент> = 5M не поместится.При среднем свободном размере блока в 11,6 КБ вероятность того, что данный элемент не уместится, возрастает после того, как его размер превышает 11,6 КБ.

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

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

0 голосов
/ 06 августа 2010

http://pecl.php.net/bugs/bug.php?id=13146 Я думаю, вам стоит продолжить или открыть новый отчет об ошибке.

...