Tarlyun blog

Сервер работал хорошо. Особых проблем не доставлял, чем сильно радовал меня, ведь мне не хотелось тратить целый декабрь на выпиливание всех ошибок. Напомню, что у меня получилось в итоге:

Сервер с 1024Мб ОЗУ, и 2000Мгц процессора, на который был установлен Centos 6. Для обслуживания сайтов было установлено:

• Apache — Веб сервер. Бэкэнд;
• Nginx — Веб сервер. Фронт;
• PHP 5.3 — Интерпретируемый язык программирования, на котором и написаны 99% моих работ;
• eAccelerator — для кэширвания PHP в байткод;
• MySQL 5.1 — База данных;
• Munin — мониторинг;

Всё работало великолепно, пока не понадобилось установить Drupal7.

Drupal

Казалось бы, все просто. Скачиваем, распаковываем, используем пошаговый мастер установки. Установщик попросил установить модуль DOM. Погуглив выясняем, что это расширение для PHP: php-xml.
Устанавливаем командой:
yum install php-xml

Вместе с установкой php-xml что-то обновилось. Я не запомнил. Но в итоге после перезапуска Apache видим 502 ошибку на всех сайтах. И как всегда, за окном суббота, 16 часов – самый пик посещаемости. К сожалению, логи не сохранились, и точно ошибку я вам не напишу. Я лишь понял, что при любом запросе падает Apache.

Очень часто советуют выполнить в консоли:

php -cgi -m

В случае ошибок должно быть видно что мешает PHP выполняться. Так же советуют отключать модули по-одному, пока не будет найден проблемный. Но в моем случае все работало. Прямой вызов скриптов с консоли не приводил к фатальным ошибкам. А раз PHP работает. Apache работает. То мешает что-то другое. Как раз между ними находится eAccelerator.

Удаляем eAccelerator — все работает. Печаль.
Пробуем установить снова eAccelerator, и настроить. Но ничего не выходит.

Понимая, что сайты без opcache оставлять нельзя — ищем замену.

APC

Поделка от разработчиков PHP. В целом, по отзывам, работает хуже eAccelerator. Ну да ладно, устанавливаем:
yum install php-pecl-apc

Пишем первый конфиг. Перезапускаем Apache. Вроде всё работает. Как оказалось не всё.
Некоторые модули и проекты перестали работать. Начались танцы вокруг конфига. И я понял куда я вляпался.
Очень часто на тематических форумах советуют просто отключать apc-cache. Но мы то его ставили не для того, что бы сразу отключить.

phpMyAdmin ERROR

[Sun Dec 25 09:40:21 2011] [error] [client 46.39.10.182] PHP Fatal error: Class 'PMA' not found in /usr/share/phpMyAdmin/libraries/common.inc.php on line 939

В интернете нашлось одно стабильное решение:
Отключить apc кэш для phpMyAdmin. Так как pma используется только мною — отсутствие opcache не критично. Делается это так:
В apc.ini надо добавить путь к pma:
apc.filter="-/usr/share/phpMyAdmin/.*"

В инициализации виртуального хоста добавить:
php_admin_value apc.enabled 0

Получится примерно так:

Order Deny,Allow
Deny from All
Allow from 111.222.111.222
Allow from ::1
php_admin_value apc.enabled 0


WordPress Admin ERROR

[Tue Dec 27 12:18:43 2011] [error] [client 46.39.10.182] PHP Fatal error: Call to undefined function is_multisite() in /var/www/sites/tarlyun.com/public_html/wp-admin/includes/admin.php on line 62, referer: http://tarlyun.com/wp-admin/post-new.php
[Tue Dec 27 12:19:14 2011] [error] [client 46.39.10.182] PHP Fatal error: Call to undefined function get_option() in /var/www/sites/tarlyun.com/public_html/wp-admin/admin.php on line 32, referer: http://tarlyun.com/

Админка WordPress отказывается работать, если в текущем конфиге установить apc.stat = 1

CodeIgniter ERROR

Сайт на CodeIgniter генерировал просто кучу разных ошибок. Проблема не в самом фреймворке. Об аналогичных проблемах с APC были репорты на форумах Zend, Kohana, Yii и других. Вот пример типичной ошибки:

Fatal error: Cannot redeclare class ci_exceptions in /my_path/system/libraries/Exceptions.php on line 27

Методом подбора получился такой конфиг:
extension = apc.so
apc.enabled = 1
apc.shm_size = 128M
apc.shm_segments = 1
apc.gc_ttl = 7200
apc.ttl = 0
apc.num_files_hint = 1024
apc.file_update_protection = 2
apc.optimization = 1
apc.include_once_override = 1
apc.max_file_size = 5M
apc.stat_ctime = 1
apc.stat = 0
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.filter="-/usr/share/phpMyAdmin/.*"

Но и здесь не всё гладко.
Из-за apc.stat = 0 (код кэшируется намертво, не проверяется изменение кода) приходится каждый раз очищать кэш APC после внесений изменений в код.
Почему-то APC использует 32М памяти. Хотя изначально, до правок конфига, он работал на 64M. Единственное решение, которое я нашел — не заработало (134217728 = 128Мб):
echo 134217728 > /proc/sys/kernel/shmmax
sysctl -p
ipcs -l
sysctl -w kernel.shmmax=134217728
ipcs -l

В целом — постараюсь вернуться на eAccelerator как можно быстрее.