Документация на php.net очень спокоен о причинах сбоя для записи APC. Какие сценарии вызовут вызов apc_store() для отказа?
В наличии достаточно свободного места на диске, а ошибки - пятнистые. Иногда операция магазина будет успешной, и иногда она терпит неудачу.
из памяти (выделенная память для apc, то есть)
Для php cli его нужно включить с помощью другой опции: apc.enable_cli = О
В моей ситуации он работал при запуске из веб-браузера, но не при выполнении одного и того же файла с php cli.
У меня была точно такая же ситуация.
Я перенес свой код с помощью Cron Jobs, используя Gearman Workers, которые управлялись через supervisord.
Все сломано. Я никогда не мог использовать кэши для работы через APC и должен был вернуться к использованию кэширования файловой базы.
В конце концов я понял, что, когда я использовал задания cron, я загружал каждую страницу через wget, а не в командную строку. Это различие означало, что supervisord, который загружал бы мои скрипты PHP через командную строку, не работал бы, потому что по умолчанию APC не будет работать через командную строку.
Исправление....
apc.enable_cli=On
этот asinine (и по какой-то причине закрыт) ошибкой была моя проблема:
http://pecl.php.net/bugs/bug.php?id=16814
должен вернуться к apc версии 3.1.2, чтобы заставить apc работать. не возиться с настройками apc в php.ini(я на Mac OS 10.5, используя apache 2, php 5.3).
для меня этот тест script показал 3 "истины" для 3.1.2 и true/false/true для 3.1.3p1
var_dump (apc_store ('test', 'one')); var_dump (apc_store ('test', 'two')); var_dump (apc_store ('diff', 'thr'));
http://php.net/manual/en/apc.configuration.php
параметры apc.ttl и apc.user_ttl на php.ini:
Оставляя это на нуле, означает, что кеш APC потенциально может заполнить устаревшие записи, в то время как новые записи не будут кэшироваться.
Из дискового пространства или разрешения, запрещенного к каталогу хранения?
В дополнение к тому, что сказал Грег, я бы добавил, что ошибка конфигурации может вызвать это.
apc_store завершится с ошибкой, если этот конкретный ключ уже существует, и вы пытаетесь снова написать его до истечения срока действия TTL. Поэтому вы можете почти игнорировать возврат false, потому что он действительно сработал, но кеш все еще существует. Если вы хотите обойти это, начните использовать apc_add. http://php.net/manual/en/function.apc-add.php
Там ошибка в версии, установленной с ubuntu 10.04 и debian stable. Если вы замените пакет на эту версию: http://packages.debian.org/sid/php-apc (3.1.7), он работает так, как должен.