对 Magento Cron 执行期间的崩溃进行故障排除
在我的工作场所，我们正在运行 Magento 1.3 店面，并且由 Magento 内部 cron 服务运行的作业遇到问题。故障排除几乎停止，因为我们无法确定哪个作业导致了问题。我们得到的唯一反馈是，每天晚上 00:05，cron 在执行 /usr/bin/php-cgi -f /path/to/app/magento 时会出现以下臭名昭著的无用 PHP 错误/html/cron.php。
PHP 致命错误：第 294 行 /chroot/magento/html/lib/Zend/Db/Statement/Pdo.php 中允许的内存大小 536870912 字节耗尽（尝试分配 50 字节）
增加 PHP 内存limit 显然不是答案 - 在 512mb 下，问题几乎可以肯定是算法正在做一些严重错误的事情，而不是我们低估了问题的要求。我们的数据库大小相当适中 - 整个数据库的明文转储小于 512mb，因此查询必须非常病态才能吃掉更多的数据。我们最好的猜测是，某些东西可能错误地使用了 Zend 的 fetchAll()，但在我们能找到的任何内容中都没有直接调用该方法。
我们怎样才能让 Magento 为我们提供堆栈跟踪或出现问题时其内部状态的其他指示？有没有一种方法可以更清楚地了解 PHP 在遇到内存墙时试图执行的内容？
理想情况下，我们希望在不修改第三方代码的情况下做到这一点 - 有时插件开发人员使用像 Zend Guard 这样的牛毛措施，或者拥有不允许我们修改其损坏代码的许可证，或者基本上让我想要去的其他措施找到斯托曼先生并给他一个温暖而感激的拥抱。
请注意，问题不是“我们如何解决内存不足错误？”这个问题以前已经被问过很多次了，并且得到了不同程度的出色回答。问题是“我们如何判断哪个 PHP 文件导致内存不足错误？”这是一个关于 Magento 内部结构的问题，而不是关于 PHP qua PHP 的问题。
At my workplace, we are running a Magento 1.3 storefront, and we are having a problem with a job that is being run by Magento's internal cron service. Troubleshooting is nearly at a halt because we can't identify which job is causing the problem. The only feedback that we're getting is that every night at 00:05, cron coughs up the following, notoriously unhelpful PHP error while executing /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
Increasing PHP's memory limit is clearly not the answer - at 512mb, the problem is almost certainly that an algorithm is doing something grievously wrong, not that we've underestimated the requirements of the problem. Our database is fairly modest in size - a plaintext dump of the entire thing is less than 512mb, so a query would have to be pretty pathological to eat more than that. Our best guess is that something is probably using Zend's fetchAll() incorrectly, but that method isn't being called directly in anything we can find.
How can we get Magento to give us a stack trace or some other indication of its internal state at the time of the problem? Is there a way to get more transparency into exactly what PHP is trying to execute when it hits the memory wall?
Ideally, we would like to do this without modifying third-party code - sometimes plugin developers use bullfeathers measures like Zend Guard, or have a license that does not permit us to modify their broken code, or other measures that basically make me want to go find Mr. Stallman and give him a warm, grateful hug.
Please note that the problem is not "how do we solve the out-of-memory error?" That's been asked many times before, and answered with varying excellence. The problem is "how can we tell which PHP file is causing the out-of-memory error?" It's a question about Magento internals, not about PHP qua PHP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议使用
Mage::log()记录多个作业的开始和结束，以便您可以将其范围缩小到任务范围。之后，只需创建一个将手动执行它的控制器，以便您可以开始调试它以解决问题。I would suggest using
Mage::log()to log the beginning and end of your multiple jobs so you can narrow it down to the task. After that just create a controller that will execute it manually so you can start debugging it to nail down the problem.如果可能的话，我会使用 Xdebug 模块运行 cronjob，并使用 Xdebug 函数跟踪 或使用 Xdebug 堆栈跟踪（如果启用 Xdebug 应该自动显示/记录堆栈跟踪）。
首先，您可能应该配置（在 php.ini 中或使用
）以下内容：
另请检查其他有趣的设置，例如 xdebug.collect_params
祝你好运！
注意：请小心输出跟踪的位置，因为它们可能包含敏感数据。
If possible I would run the cronjob with the Xdebug module, with Xdebug function trace or with Xdebug stack trace (which if Xdebug is enabled should display/log the stack trace automatically).
For the first, you should probably configure (either in php.ini or by using
) the following:
Also check other interesting settings like xdebug.collect_params
Good luck!
NB: be careful where you output the traces since they probably contain sensitive data.