New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak with LogEventInfo object #2220
Comments
Upgrade to newest NLog, and add the following setting to your AsyncWrapper-configurations:
By default the AsyncWrapper will keep the LogEventInfo's alive for 50 ms before flushing to target. This is long enough for the LogEventInfo's to be upgraded to GC1, and causing unnecessary garbage. See also #1757 |
You can also increase the batchSize for the AsyncWrapper-configurations (Increasing it higher than 1000 will give extra memory allocations):
This will help when using a file-target with |
Thanks for those details. I will test them out. Is there a code example for the overriding the "Write" method for bulk handling of a custom target? I can't find any examples for the following overrides: |
Just ignore my suggestions about improving the bulk-handling in AprimoAITarget and EventLog. They are only used for occasional Warnings and Errors. They will not be affected by lowering the log-level to Debug or Trace for the asyncFile. |
@earlgumbo3 Were you able to resolve you problem? If so can you tell what fixed it? (And maybe close this issue) |
@snakefoot We are currently in QA and testing your suggested configuration changes. So far, my local testing looks good, and we are actually getting a performance boost from this configuration. I should be able to close this issue soon. The release will go RC tomorrow. Thanks for all the help. I'll be sure to close this once our official QA is completed. |
This issue was resolved using the suggestions posted above. |
Hi! Thanks for reporting this feature/bug/question!
Please keep / fill in the relevant info from this template so that we can help you as best as possible.
For .NET Core users, please check the platform support: https://github.com/NLog/NLog/wiki/platform-support
Type (choose one):
NLog version: All
Platform: .Net 4.0 / .Net 4.5
Current NLog config (xml or C#, if relevant)
In case of a BUG:
What is the current result?
There is a large increase in memory consumption when the logging level is set to "Trace", and there are a large number of logging statements for verbose debugging in an application. This is leading to NLog objects (specifically the LogEventInfo object, and its associated string data) being placed in Gen2 or higher memory heaps where they persist longer than necessary, which in turn leads to high memory consumption, or even overflow.
What is the expected result?
The LogEventInfo objects should be destroyed after the event it written to the NLog targets that apply.
Did you checked the Internal log?
Yes.
Please post full exception details (message, stacktrace, inner exceptions)
There are no exception details for this issue. It will require a memory dump analysis to determine if the objects are being disposed of properly before they end up in higher generation memory heaps.
Are there any work arrounds? yes/no
The workaround for this issue is to turn logging levels up to "Warn" or above, and ensure that the underlying application is not making excessive logging calls that would cause additional NLog objects to be created.
Is there a version in which it did worked?
No.
Can you help us by writing an unit test?
N/A
The text was updated successfully, but these errors were encountered: