Я настраиваю APC (v 3.1.9) на установке WordPress с высоким трафиком на 64-разрядной версии CentOS 6.0.
Я выяснил многие причуды APC, но что-то все еще не совсем так. Независимо от того, какие настройки я меняю, APC никогда не кэширует больше 32 МБ. Пытаюсь поднять до 256 МБ. 32 МБ - это размер по умолчанию для apc.shm_size, поэтому мне интересно, застрял ли он там как-то.
Я выполнил следующее
echo '2147483648' > /proc/sys/kernel/shmmax
чтобы увеличить общую память моей системы до 2 Гб (половина моей коробки 4G). Затем побежал
ipcs -lm
который возвращается
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 2097152
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1
Также внесены изменения в
/etc/sysctl.conf
затем побежал
sysctl -p
чтобы настройки оставались на сервере. Перезагрузил тоже для хорошей меры.
В моих настройках APC включен mmap (что происходит по умолчанию в последних версиях APC). php.ini выглядит так:
apc.stat=0
apc.shm_size="256M"
apc.max_file_size="10M"
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.ttl="7200"
Я знаю, что режим mmap игнорирует ссылки на apc.shm_segments, поэтому я оставил его по умолчанию 1.
phpinfo () указывает на APC следующее:
Version 3.1.9
APC Debugging Disabled
MMAP Support Enabled
MMAP File Mask /tmp/apc.bPS7rB
Locking type pthread mutex Locks
Serialization Support php
Revision $Revision: 308812 $
Build Date Oct 11 2011 22:55:02
Directive Local Value
apc.cache_by_default On
apc.canonicalize O
apc.coredump_unmap Off
apc.enable_cli Off
apc.enabled On On
apc.file_md5 Off
apc.file_update_protection 2
apc.filters no value
apc.gc_ttl 3600
apc.include_once_override Off
apc.lazy_classes Off
apc.lazy_functions Off
apc.max_file_size 10M
apc.mmap_file_mask /tmp/apc.bPS7rB
apc.num_files_hint 1000
apc.preload_path no value
apc.report_autofilter Off
apc.rfc1867 Off
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.rfc1867_ttl 3600
apc.serializer default
apc.shm_segments 1
apc.shm_size 256M
apc.slam_defense On
apc.stat Off
apc.stat_ctime Off
apc.ttl 7200
apc.use_request_time On
apc.user_entries_hint 4096
apc.user_ttl 0
apc.write_lock On
apc.php показывает следующий график вне зависимости от того, как долго работает сервер (размер кеша колеблется и составляет чуть менее 32 МБ.
См. Изображение http://i.stack.imgur.com/2bwMa.png
Вы можете видеть, что кеш пытается выделить 256 МБ, но коричневый кусок пирога продолжает использоваться на 32 МБ. Это подтверждается тем, что при обновлении страницы apc.php отображаются счетчики кешированных файлов, которые меняются вверх и вниз (подразумевая, что кеш не удерживает все свои файлы).
Кто-нибудь знает, как заставить APC использовать более 32 МБ для размера кеша ??
** Обратите внимание, что идентичное поведение происходит для eaccelerator, xcache и APC. Читаю здесь:
http://www.litespeedtech.com/support/forum/archive/index.php/t-5072.html
что suEXEC может вызвать эту проблему.
Фактическая проблема - частый перезапуск Apache, который не позволяет APC создавать кеш. Я не комментирую размер памяти для wordpress. Вы используете cPanel? Он имеет функцию ротации журналов, которая перед ротацией журналов перезапускает Apache, хотя это плавный перезапуск, но очищает весь кеш APC. Вы можете либо увеличить порог ротации журналов, либо посмотреть, почему он так быстро достигает предела. Возможно, вы можете включить Piped Log в конфигурации Apache (в cPanel).
Эта ссылка расскажет вам, как можно сделать и то, и другое.
http://forums.cpanel.net/f5/cpanel-11-25-log-processing-145417.html
попробуйте поднять
apc.shm_segments 1
тогда посмотрим, что произойдет
Это может быть не для запуска, но тестировали ли вы это с чем-нибудь, кроме этого экземпляра wordpress? Есть ли шанс, что у вас действительно только ~ 32 МБ доступного контента?
APC будет кэшировать только код, который активно используется - когда у него много памяти, то единственное, что удалит код из кеша, - это TTL.
Увеличение TTL увеличит заполняемость.