php - Symfony2 给出空白页

Question

Symfony 2 死机并给我空白页。免责声明:我讨厌空白页。无论如何，我如何找出问题所在？为什么它死了；为什么没有错误？

检查 dev.log 它给了我无用的信息:

[2011-08-05 08:41:33] doctrine.DEBUG: UPDATE accTransactions SET report_id = ? WHERE id = ? ([8163,2941852])
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.view" to listener "Sensio\Bundle\FrameworkExtraBundle\EventListener\TemplateListener::onKernelView".
[2011-08-05 08:41:33] event.DEBUG: Listener "Sensio\Bundle\FrameworkExtraBundle\EventListener\TemplateListener::onKernelView" stopped propagation of the event "kernel.view".
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.response" to listener "Symfony\Component\HttpKernel\EventListener\ResponseListener::onKernelResponse".
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.response" to listener "Symfony\Bundle\SecurityBundle\EventListener\ResponseListener::onKernelResponse".
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.response" to listener "Symfony\Bridge\Monolog\Handler\FirePHPHandler::onKernelResponse".
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.response" to listener "Sensio\Bundle\FrameworkExtraBundle\EventListener\CacheListener::onKernelResponse".
[2011-08-05 08:41:33] event.DEBUG: Notified event "kernel.response" to listener "Symfony\Component\HttpKernel\EventListener\ProfilerListener::onKernelResponse".
[2011-08-05 08:41:35] event.DEBUG: Notified event "kernel.response" to listener "Symfony\Bundle\WebProfilerBundle\EventListener\WebDebugToolbarListener::onKernelResponse".

php_error.log等没有报错。

我在一个大表上运行更新，每个请求执行大约 1500 多个查询(大约需要 15 秒)。我假设 PHP 的消亡与 Doctrine2 有关。它非常不稳定，因为当交易数量似乎增加时它开始死亡......我必须管理我对 ORM 的期望更多，而不仅仅是空白死亡。

是否有数据库日志文件或其他可以给我错误的东西？除了一次处理 1 笔交易之外，还有其他任何事情要做，因为这需要 13,333 小时……如果您查看第一个日志条目，这是一个非常基本的更新(只需添加一个关系)。

我正在使用 APC 运行 PHP 5.3.2

我还注意到，当函数到达底部的 flush 命令时，它成功执行了它。 因此，我假设现在只有 SF2 没有成功呈现 View ？

Answer 1

如果您在 Doctrine2 中进行批处理，那么您的实体管理器将会增长，并且您正在违反 PHP 内存限制。

http://www.doctrine-project.org/blog/doctrine2-batch-processing.html

您正在创建数以千计的对象，并且每个周期都在增长。

在使用 ORM 进行批处理时要小心，以消除内存泄漏。 ORM 并不总是这项工作的最佳工具，但如果您对自己所做的事情小心谨慎，则可以使用它。