Почему APC увеличивает “Кэш полное количество” для Пользовательского Кэша даже при том, что это имеет много доступной памяти?
Я играл с этим долгое время, но в чем-то вроде потери относительно того, что сделать. Я использую 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, но просто хотеть упомянуть это в случае, если это важно в решении проблемы под рукой. После нескольких часов это поражает равновесие приблизительно 30k записи.
Фрагментация начинается рано и растет быстро. В течение, возможно, приблизительно 10 часов я обычно при 100%-й фрагментации.
В целом (код операции + пользователь) использование кэша стабилизирует приблизительно 240 МБ или около этого. Это никогда не будет фактически выходить за предел того уровня. Приблизительно после одного дня я начну видеть, что Пользовательский кэш кэша полное количество (UCCFC) увеличивает.
Во время этой записи моего UCCFC в 62 358 и растущий несмотря на APC, сообщая о свободных 280 МБ. У меня есть user_ttl 7 200, но я также играл с установкой его к 0 или другие суммы, и он имеет мало бесцельно на проблеме.
Я подозреваю, что проблема имеет некоторое отношение к фрагментации. Прямо сейчас мой сервер сообщает "о Фрагментации: 100,00% (280,0 мегабайта из 280,0 мегабайтов в 24 740 фрагментах)" и 280 МБ именно так, оказывается, количество свободного пространства, о котором сообщает APC; выразительное совпадение, я думаю. К сожалению, я нашел драгоценную небольшую информацию в документах или в другом месте указать, что "фрагментация" действительно означает в мире APC и там, кажется, фактически ничто, что можно сделать для предотвращения его.
Кто-либо может пролить какой-либо свет на эту проблему?
2 ответа
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,6 КБ.
Это означает, что если вы попытаетесь сохранить элемент, размер которого превышает все доступные блоки, он не поместится, и произойдет одно из двух, в зависимости от параметра конфигурации apc.user_ttl . Если TTL установлен на 0, то весь ваш пользовательский кеш очищается и элемент вставляется. Если TTL установлен больше 0, он будет сбрасывать просроченные записи и вставлять элемент. В обоих случаях увеличивается счетчик полного кеширования. Наличие такого приращения, как и в вашем случае, является индикатором того, что вы, возможно, делаете это неправильно .
Вот простая визуализация того, что фрагментация делает с вашим кешем с течением времени. Он представляет собой простой 32-байтовый размер кеш-памяти, каждый блок составляет 1 Байт.
[--------------------------------] (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 спокойно выполнять свою работу.
http://pecl.php.net/bugs/bug.php?id = 13146 Думаю, вам следует продолжить с этого или открыть новый отчет об ошибке.