На моем рабочем месте у нас работает магазин Magento 1.3, и у нас возникла проблема с заданием, выполняемым внутренней службой cron Magento. Устранение неполадок практически остановлено, потому что мы не можем определить, какая работа вызывает проблему. Единственный ответ, который мы получаем, это то, что каждую ночь в 00:05 cron выдает следующую, печально известную бесполезную ошибку PHP при выполнении /usr/bin/php-cgi -f /path/to/app/magento/html/cron.php.
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 50 bytes) in /chroot/magento/html/lib/Zend/Db/Statement/Pdo.php on line 294
Увеличение лимита памяти PHP явно не ответ - на 512 Мб, проблема почти наверняка в том, что алгоритм делает что-то ужасно неправильное, а не в том, что мы недооценили требования проблемы. Наша база данных довольно скромна по размеру - дамп открытого текста всего этого составляет менее 512 Мб, поэтому запрос должен быть довольно патологичным, чтобы съесть больше. Наше предположение состоит в том, что, вероятно, что-то неправильно использует Zend fetchAll (), но этот метод не вызывается напрямую во всем, что мы можем найти.
Как мы можем заставить Magento дать нам трассировку стека или какое-либо другое указание на его внутреннее состояние во время проблемы? Есть ли способ добиться большей прозрачности в том, что именно PHP пытается выполнить, когда попадает в стену памяти?
В идеале, мы хотели бы сделать это без изменения стороннего кода - иногда разработчики плагинов используют меры bullfeathers, такие как Zend Guard, или имеют лицензию, которая не позволяет нам изменять их неработающий код, или другие меры, которые в основном делают меня хочу найти мистера Столлмана и тепло обнять его.
Обратите внимание, что проблема не в том, "как мы решаем ошибку нехватки памяти?" Об этом уже много раз спрашивали, и отвечали с переменным превосходством. Проблема в том, «как мы можем определить , какой файл PHP вызывает ошибку нехватки памяти?» Это вопрос о внутренностях Magento, а не о PHP qua PHP.