Крупный проект на PHP. Выкатываем новую версию на сервер — потребление памяти (memory_get_peak_usage в конце исполняемого кода) выросло в два раза.
Переполошились, начали копать.
Отключение eAccelerator показывает, что и старая и новая версии потребляют одинаково.
Включаем eA — опять разница в два раза.
Собственно, вопросы:
1. Поскольку потребление памяти одни и тем же скриптом с выключенным eA и с включенным eA заметно отличается, то был сделан вывод, что в случае работающего eA в потребляемую память не засчитывается опкод самого скрипта, ибо он лежит в разделяемой памяти. Так ли это? Если это не так, то чем ещё можно объяснить колоссальную разницу в результате memory_get_peak_usage в одинаковых условиях?
2. И самое главное: каково может быть разумное объяснение поведения, изложенного в первой части? Когда без eA расход памяти не изменился (и мы склонны этому верить), а при включении eA выдаётся совершенно нереальный прирост потребления.
1. Не совсем понял вопрос «о каких цифрах»… Если интересует конкретика, то данные таковы:
old code wo eA: ~11Mb
old code with eA: ~4Mb
new code wo eA: ~11Mb
new code with eA: ~8Mb
2. используем только кэш опкода
3. версия eA самая свежая
вас так волнует лишние 4 МБ?
если да, считайте тогда уж средневзвешенное с весами по веремени исполнения, возможно вы только выигрываете
и да, новая версия кода не всегда означает хорошая )
когда нечего сказать — лучше промолчать.
потребление памяти возросло в два раза. 4 Mb это самый лёгкий запрос, есть гораздо тяжелее.
время выполнения считается отдельно и к данному вопросу отношения не имеет.
вопрос здесь в том, откуда возникла разница в потреблении под eA, если без него разницы нет, то есть скрипт больше потреблять точно не стал.
отключать оптимизацию пробовали?
оптимизации там следующие:
-предвычисления
-оптимизации переходов
-превращение глупых вызовов функций в меньшее количество умных вызовов (типа $a=$a+1; превращает в $a++; а в свою очередь $a++; превращает в ++$a; поэтому все оптимизации делаются 2 раза)
-быстрые вызовы стандартных функций
-склеивание блоков
шутка в том что всё это происходит на одном дереве, а значит ситуации когда первый проход склеит кучу блоков в один, а второй «оптимизирует» хитрый условный указатель на этот блок путём дублирования блока — не исключены
на самом деле это тоже оптимизация, но в случае акселератора не контролируется размер дублируемых блоков, поэтому может выйти казус
а возможно я не прав, и бага в чём то ещё
на вашем месте я бы отключил оптимизатор, посмотрел что выйдет и в любом случае постарался бы накатывать новую версию маленькими шажками(если такое возможно) чтобы отловить сначала файл из за которого растёт потребление памяти, ну а потом уже и в файле то же самое чтобы понять причину (вообщем самая настоящая отладка получается)
