Как отлаживать ошибки "Symfony \ Component \ Debug \ Exception \ FatalErrorException" в PHP (Laravel)?

Если вы не уверены в причине исключения, вы можете обработать его двумя способами.

1 увеличить время ожидания запроса ini_set ('max_execution_time', 60); // 60 секунд = 1 минута

2 оберните свой код в try catch

try{
  //logic goes here
}catch(\Excaption $e){
 Log::error($e->getMessage().' '. $e->getFile().' '. $e->getLine());
 return back()->with('error',$e->getMessage() );
}

Я не думаю, что вам стоит пока увеличивать тайм-аут. если вы сделаете «попытаться поймать», вы сможете понять основную проблему. Если нет, проверьте операции / функции, выполняемые в конкретном методе или классе. Есть вероятность, что вы запрашиваете огромную таблицу и, возможно, пытаетесь использовать информацию.

если ты это сделаешь

\DB::listen(function ($sql) {
        var_dump($sql);
   });

это даст вам представление о том, сколько запросов выполняется для операции

Невозможно отловить это с помощью try catch, поскольку на самом деле это ошибка PHP, а не исключение.

Чтобы отладить это, у вас есть несколько вариантов:

1. Добавьте несколько журналов в код, чтобы определить, где истекает время ожидания
2. Вы можете использовать Пакет сервера дампа Laravel для выгрузки логов. На самом деле он будет поставляться с Laravel 5.7, но вы всегда можете добавить пакет сейчас.

Я установил laravel-debugbar, думаю, вам это поможет.

композитору требуется barryvdh / laravel-debugbar Затем откройте config / app.php и внутри массива «поставщиков» добавьте:

Barryvdh\Debugbar\ServiceProvider::class,

в классе массива псевдонимов:

'Debugbar' => Barryvdh\Debugbar\Facade::class,

и вы можете просмотреть

Debugbar::measure('My long operation', function() {

// Сделай что-нибудь… });

Можете ли вы зарегистрировать функцию выключения? Функция выключения вызывается даже при истечении времени ожидания. С его помощью вы можете распечатать или сохранить то, что хотите, в файл журнала. Я не уверен, есть ли лучший способ получить обратную трассировку в laravel, но я бы, вероятно, сделал это в чистом php (вызовите debug_backtrace).

<?php

function timedOut() {
    //save to a log file instead of printing
    var_dump(debug_backtrace());
}

register_shutdown_function("timedOut");

http://php.net/manual/en/function.register-shutdown-function.php

http://php.net/manual/en/function.debug-backtrace.php

Прочитав вашу беседу в чате, я увидел, что вы используете эту конфигурацию .env:

CACHE_DRIVER=file 
SESSION_DRIVER=file 

Думаю, в этом проблема ... Объясняюсь немного лучше.

Когда вы используете драйвер file для кеша или сеанса, Laravel создаст тонны файлов, в которых хранятся данные сеанса пользователей или данные кеша приложений ...

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

Я думаю, это может быть два возможных решения:

• Ваша производственная среда должна быть обновлена ​​(я не знаю спецификации вашего производственного сервера и достаточно ли у вас ресурсов).
• Файловый драйвер становится слишком медленным для требований вашего приложения.

Я обычно использую Redis в качестве драйвера кэша и сеанса, он быстрее и с хорошей стратегией «умного кэширования» это отличный инструмент.

Я думаю, вам стоит попробовать использовать и его, если возможно. Memcached тоже может быть хорошим решением.

Честно говоря, вам лучше всего установить xdebug и просто отладить его по старинке, пройти весь запрос, чтобы найти узкое место, и попытаться выяснить, откуда оно взялось. Laravel, как и другие фреймворки, был разработан для максимально плавной работы. Если вы столкнулись с подобными ошибками, это означает, что вы просто что-то неправильно запрограммировали.

Также сложно дать вам конкретный совет без дополнительной информации. Я бы предложил воссоздать спецификации среды (вы можете использовать Docker или Vagrant или что-то еще, что придет вам в голову, что будет работать), с которым сталкивается ваше приложение Laravel, а затем запустить с xdebug, чтобы найти, в чем проблема.

Вы не можете поймать ошибку тайм-аута php. Эта ошибка возникает, когда интерпретатор php прекращает выполнение. Вы можете только увеличить ограничение по времени, например, ini_set ('max_execution_time', 300), или преобразовать длительную работу по выполнению в задание cron, например, расписание задач laravel.

Я не привык к Laravel, но у меня была эта проблема, и я решил ее с помощью PHP-функции register_shutdown_function.

Я обнаружил, что это очень полезно для отслеживания случайных ошибок. Вот как я это делаю в своем коде. Вы можете поместить это где-нибудь в общий файл, который будет выполняться на каждой странице, index.php будет для вас хорошим вариантом, поскольку все маршруты Laravel проходят через него (мое предположение).

register_shutdown_function( "check_for_fatal" );

function check_for_fatal(){
    $time = time(); //time when this error occurred

    $error = error_get_last();
    if (in_array($error["type"], [E_ERROR, E_CORE_ERROR, E_RECOVERABLE_ERROR])){
        $email_body = [];
        $email_body[] = 'Date: ' . date('m-d-Y H:i:s', $time);
        ob_start();
        var_dump($error);
        $email_body[] = ob_get_clean();
        //include any other data as needed
        //$body[] = "add data as appropriate";

        //You can email it to yourself, but if there are lots of errors you will be bombarded with emails
        mail('[email protected]', 'Subject', implode("\r\n", $email_body));
       //or you can save this to some log file
    }
}

Похоже, PHP ждет какого-то ресурса, например. файловый доступ, база данных, почтовый сервер (думаю файл).

• Вы пробовали использовать свое приложение на многих вкладках за один сеанс?
• Вы пробовали войти в одну и ту же учетную запись на многих машинах?
• Может быть, какая-то часть скрипта открывает файл, а не закрывает его?
• Вы отслеживали действия пользователей при открытии сайта, чтобы получить эту ошибку?
• Проверьте свою производственную базу данных - может быть, очень маленький лимит подключений?

РЕДАКТИРОВАТЬ

Я вижу, что вы используете библиотеку dannyvankooten/vat.php, которая делает некоторые запросы к внешним сервисам. Это может быть источником ваших проблем. Эта библиотека делает запросы с помощью curl. Автор устанавливает CURLOPT_CONNECTTIMEOUT, но CURLOPT_TIMEOUT не установлен, и ваш сценарий иногда может ждать дольше, чем это ограничено настройкой max_execution_time.

Новая версия часовой предоставит вам правильную трассировку стека.

Вы должны использовать версию "getsentry / sentry-php"> = "2.0"

• Вот проблема, о которой сообщается: https://github.com/getsentry/sentry-php/issues/761
• Вот PR для исправления: https://github.com/getsentry/sentry-php/pull/763