Ошибка рабочего режима Symfony 4 Исчерпана память для обработки страниц

Я установил свой проект в режим prod в .env, и все, кроме настраиваемых страниц ошибок, похоже, работает.

У меня это шаблон веточки 404:

{# templates/bundles/TwigBundle/Exception/error404.html.twig #}
{% include 'builder/layout/header.html.twig' with {'title': '404'} %}

<img src = "{{ assets('img/not-found.jpeg') }}" class = "img-responsive"
     id = "error-not-found-img" />

<div class = "http-error-msg-container">
    <h1>404! Page Not Found</h1>
    <p>Don't despair, go back to <a href = "{{ path('dashboard') }}">Home</a> and try again.</p>
</div>

{% include 'builder/layout/footer.html.twig' %}

а переход на несуществующую страницу (скажем, /dashboard/giorgoirdjfisejf) возвращает пустую страницу. Итак, я добавил это в свой файл index.php:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(-1);

чтобы показать ошибки, и я получил это:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/solomon/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php on line 107

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32768 bytes) in /var/www/solomon/vendor/symfony/debug/Exception/OutOfMemoryException.php on line 1

Я не совсем уверен, почему это вызывает ошибку и не может отлаживать. var/log/prod.log ничего не показывает, как мне разрешить или еще лучше, как отладить?

Обновить

мой файл prod / monolog.yaml

monolog:
    handlers:
        main:
            type: fingers_crossed
            action_level: error
            handler: nested
            excluded_404s:
                # regex: exclude all 404 errors from the logs
                - ^/
        nested:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
        console:
            type:   console
            process_psr_3_messages: false
            channels: ["!event", "!doctrine"]

это было создано автоматически, и я не внес изменений

Он пытается зарегистрировать что-то большое, поэтому он вылетает, и это причина, по которой в вашем prod.log ничего нет. Попробуйте на своем локальном компьютере с memory_limit -1, и вы увидите, что это такое

Eakethet 15.06.2018 14:06

Какой ТИП обработчика?

delboy1978uk 15.06.2018 14:07

в вашей конфигурации yaml для монолога, какой тип обработчика журнала вы используете?

delboy1978uk 15.06.2018 14:25

Попробуйте добавить buffer_size: 200 в конфиг обработчика

delboy1978uk 15.06.2018 14:25
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
9
4
4 419
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Проверьте права доступа к файлам журналов Symfony. Похоже, что monolog перехватывает исключение permission denied, пытается записать его в журнал и снова и снова обнаруживает одну и ту же ошибку.

забыл на самом деле проверить журнал ошибок, черт возьми, это показало фактическую ошибку, и я сразу ее разрешил :)

treyBake 15.06.2018 14:37

В моем случае сообщение об ошибке было почти идентичным, за исключением того, что трассировка стека всегда указывала на строку 171 в StreamHandler.php. Проблема заключалась в том, что Composer был запущен в Windows, и полученные файлы были скопированы в систему Linux. Это привело к использованию неправильного разделителя каталогов, и Symfony затем попыталась создать /var/www/html/var\log/prod.log (содержит обратную косую черту), что, очевидно, не удалось.

Поэтому обязательно запускайте Composer в той же ОС, на которой вы будете запускать приложение позже.

Другие вопросы по теме