You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
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.
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:
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.
The text was updated successfully, but these errors were encountered: