WordPress: admin.php поедает память

Сегодня обнаружил пренеприятную вещь. Если в WP, будучи авторизованным, производить какие-либо действия, через некоторое время сайт перестаёт отзываться и выпадает в осадок на непродолжительное время. После этого всё опять начинает работать, как ни в чём не бывало, до следующего такого же события. Я полез в логи в поисках источника проблемы. В /var/log/syslog я нашел исчерпывающую информацию:

1
Dec 22 20:39:41 < хост убран > suhosin[19857]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '< ip убран >', file 'wp-admin/admin.php', line 109)

Оказалось, что это полезняшка-Suhosin прибивает скрипт wp-admin/admin.php по причине того, что последний по непонятной причине начинает жрать очень уж много памяти. Гораздо больше, чем задано в настройках PHP. Начав копаться в движке, я обнаружил, что разработчики весьма щедро одарили свой движок памятью (wp-includes/default-constants.php:27):

1
2
3
if ( ! defined( 'WP_MAX_MEMORY_LIMIT' ) ) {
    define( 'WP_MAX_MEMORY_LIMIT', '256M' );
}

Подобная запись присутствовала в WP и раньше. Тогда значение просто было жёстко прописано в те же 256Мб. В конфиге php у меня установлено максимальное значение в 128Мб. Именно по этой причине Suhosin и валил выполняющийся скрипт.

На данный момент я не очень представляю, чего же такого делает admin.php, что требует больше 128 мегабайт памяти. Особенно учитывая, что это происходит во время отправки комментария. Не смотря на то, что скрипту требуется память, я решил не раздвигать установленные в 128Мб рамки. Скорее наоборот, я решил придавить WordPress этими 128 мегабайтами. Как видно из кода выше, это совсем нетрудно сделать — достаточно определить константу WP_MAX_MEMORY_LIMIT в wp-config.php:

1
define( 'WP_MAX_MEMORY_LIMIT', '128M' );

Тогда вышеупомянутый код в wp-includes/default-constants.php не будет выполняться. Конечно, это полурешение. Более того, я ожидаю, что, если скрипту понадобится больше 128Мб, он также будет убиваться, но уже интерпретатором PHP. Однако, я все же посмотрю, как оно будет работать.

Похожие статьи:

Запись опубликована в рубрике Wordpress с тэгами , , , . Создать закладку на запись. Оставить комментарий или trackback: Trackback URL.

2 комментариев

  1. Опубликован 18 Июль 2012 в 11:18 | Прямая ссылка

    а как установить какой конкретно скрипт жрет память?

    • Опубликован 18 Июль 2012 в 21:48 | Прямая ссылка

      Можно определить по записям в логах, как например, в первой вставке кода в этой статье. Если же ты имеешь в виду определение скрипта, который был подключен в том, который описан в логах, то тут вариантов всего ничего. Первый — поставить что-нибудь типа xdebug, тогда в логах, выводе в консоль и/или (в зависимости от настроек) в выводе в браузер появятся уведомления о вызовах функций в несколько уровней вложенности. Благодаря этому можно отследить, какой же именно скрипт виноват. Однако, я настоятельно рекомендую не ставить xdebug на продакшн-сервере, т.к. это приведет к открытию важной информации, совершенно не нужной посетителям, и возможно поломает разметку страницы. В такой ситуации, когда все-таки нужно отследить утечки памяти и прочие глюки с xdebug, лучше сделать это на тестовом сервере. Пусть даже у себя на рабочем компьютере. Можно более интенсивно использовать xdebug — при ручном дебаггинге кода, когда вносятся изменения в собственно код для получения данных от профилировщика xdebug, после исследования которых можно получить много хорошей информации об узких местах в скрипте. А второй вариант — руками, посредством ряда экспериментов. Такой вариант долог, менее удобен в виду того, что придется вручную прочесывать чуть ли не весь код, который непосредственно либо опосредованно инклюдится в этот файл.

Оставить комментарий

Ваш e-mail никогда не будет опубликован или передан третьим лицам. Обязательные поля отмечены *

*
*