Symfony2 daje pustą stronę

Question

Symfony 2 umiera i daje mi pustą stronę. Zastrzeżenie: Nienawidzę pustych stron. W każdym razie, w jaki sposób dowiedzieć się, co poszło nie tak; dlaczego umarł; dlaczego nie ma błędu?

Sprawdzanie dev.log daje mi bezużyteczną informację:

[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 i inne nie mają błąd.

Uaktualniam dużą tabelę i wykonuję około 1500 zapytań na żądanie (co zajmuje około 15sek). Zakładam, że śmierć PHP ma coś wspólnego z Doctrine2. Jest bardzo niestabilny, ponieważ zaczyna ginąć, gdy liczba transakcji wydaje się rosnąć ... Muszę administrować, że oczekiwałem znacznie więcej od ORM, a nie tylko pustych zgonów.

Czy istnieje plik dziennika db lub coś, co może dać mi błąd? Wszystko do pracy, oprócz wykonywania jednej transakcji na raz, ponieważ zajmie to 13 333 godziny ... Jest to bardzo prosta aktualizacja (wystarczy dodać tę jedną relację), jeśli spojrzysz na pierwszy wpis dziennika.

Używam PHP 5.3.2 z APC

Zauważyłem również, że gdy funkcja dostaje polecenia równo na dnie, to z powodzeniem wykonuje go. W związku z tym zakładam, że to tylko SF2 teraz, że nie renderowania widoku pomyślnie?

Answer 1

Jeśli przetwarzasz wsadowo w Doctrine2, to twój menadżer podmiotu będzie się powiększał i przekroczysz limit pamięci PHP.

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

Tworzycie tysiące obiektów i ta rośnie z każdym cyklem.

Należy zachować ostrożność podczas przetwarzania wsadowego przy użyciu metody ORM, aby wyeliminować wycieki pamięci. ORM nie zawsze jest najlepszym narzędziem do tej pracy, ale można go użyć, jeśli jesteś ostrożny z tym, co robisz.

Answer 2

Myślę, że powinieneś włączyć i sprawdzić swój dziennik zapytań MySQL. Na Debian Linux należy edytować plik /etc/mysql/my.cnf i edytować go więc powinien on mieć coś podobnego do

[mysqld] 
# ... 

# * Logging and Replication 
# 
# Both location gets rotated by the cronjob. 
# Be aware that this log type is a performance killer. 
# As of 5.1 you can enable the log at runtime! 
general_log_file  = /var/log/mysql/mysql.log 
general_log    = 1 
log_error    = /var/log/mysql/error.log 

więc szukać będziesz mógł go zobaczyć w czasie rzeczywistym przez tail -F /var/log/mysql/mysql.log

Answer 3

Spróbuj dodać „cache: false "twig w pliku konfiguracyjnym dla twojego środowiska. Rozwiąż mnie.

Answer 4

spróbować usunąć te foldery: - cache - kłody

i przeładuj stronę.