Memory Increment on Mass Data Logging Due to Ignition's LogRecorder when APP_DEBUG=FALSE

[Kristian4078]

When logging a significant amount of data in a single request, I observed a consistent increase in memory usage. This increment persisted even after logging my message and explicitly clearing it from memory.

Upon further investigation, I found that the culprit is Spatie\LaravelIgnition\Recorders\LogRecorder. It continuously stores all logged messages within the $this->logMessages[] property, regardless of whether the Laravel application's APP_DEBUG is set to FALSE.

In a non-debug environment, one would expect that these Exception interfaces aren't thrown, and thus, Ignition should not execute. However, this behavior persists even when the application is not in debug mode. Furthermore, setting enable_runnable_solutions to FALSE did not resolve the issue.

To circumvent this behavior, which I perceive as a memory leak in production, I've adjusted my Ignition configuration as follows:

$config = [ /* ... original configuration ... */];

if (env('APP_DEBUG', false) == false) {
    $config['recorders'] = [];
    $config['argument_reducers'] = [];
    $config['solution_providers'] = [];
    $config['with_stack_frame_arguments'] = false;
    $config['enable_runnable_solutions'] = false;
}

return $config;

This temporary fix ensures efficient memory usage in production, as we don't want unnecessary memory consumption when we aren't debugging or displaying Ignition messages.

I believe it would be beneficial for the package to address this behavior, ensuring that memory isn't wastefully used in production environments.

[dusanbre]

Yes, I had the same problem, the only difference is that I used a Bulk insert. There is an event in the library that logs all queries in memory. Please fix this.

[MaartenWaegeman]

I'm having similar issues, where I have a job that needs to insert 1M+ records and it fails due to running out of memory.

[slakbal]

@freekmurze @timvandijck I have the same issue here. I'm doing bulk inserts of mass data using a generator and DB:insert(). Ignition is eating up the memory. Once I removed it from composer.json memory stayed stable. Maybe an easy solution is to be able to disable ignition at runtime... ie. Ignition:disable() so that it can be disabled for the request life-cycle, or a queued job, etc.

[Radiergummi]

This also affects our Elasticsearch client library, which connects the Elasticsearch PSR logger to a Laravel channel. As Elasticsearch tends to log huge requests, this quickly fills up available memory and crashes the application.

[spatie-bot]

Dear contributor,

because this issue seems to be inactive for quite some time now, I've automatically closed it. If you feel this issue deserves some attention from my human colleagues feel free to reopen it.