I'm trying to figure out a memory leak in my app which only happens in production, as such instrumentation would cripple the performance, so I thought about using NLOG and output the process' processinfo:PrivateBytes64/PagedSystemMemorySize64 in the log to try to find the exact spot where memory grows unexpectedly. The problem is that since this is a IIS process, private bytes are pretty much constant despite the fact that IIS reports it is ever increasing at a fast pace. So I'm now trying to output the system memory usage instead of the process information itself. I've analyzed all available layout renders and didn't find one (or missed the one) for system information!
Did I really missed it? Here are the available layout renderers:
${activityid} - Puts into log a System.Diagnostics trace correlation id.
${all-event-properties} - Log all event context data.
${appdomain} - Current app domain.
${assembly-version} - The version of the executable in the default application domain.
${basedir} - The current application domain's base directory.
${callsite} - The call site (class name, method name and source information).
${callsite-linenumber} - The call site source line number.
${counter} - A counter value (increases on each layout rendering).
${date} - Current date and time.
${document-uri} - URI of the HTML page which hosts the current Silverlight application.
${environment} - The environment variable.
${event-properties} - Log event properties data - rename of ${event-context}.
${exception} - Exception information provided through a call to one of the Logger.*Exception() methods.
${file-contents} - Renders contents of the specified file.
${gc} - The information about the garbage collector.
${gdc} - Global Diagnostic Context item. Dictionary structure to hold per-application-instance values.
${guid} - Globally-unique identifier (GUID).
${identity} - Thread identity information (name and authentication information).
${install-context} - Installation parameter (passed to InstallNLogConfig).
${level} - The log level.
${literal} - A string literal.
${log4jxmlevent} - XML event description compatible with log4j, Chainsaw and NLogViewer.
${logger} - The logger name.
${longdate} - The date and time in a long, sortable format yyyy-MM-dd HH:mm:ss.ffff.
${machinename} - The machine name that the process is running on.
${mdc} - Mapped Diagnostics Context - a thread-local structure.
${mdlc} - Async Mapped Diagnostics Context - a thread-local structure.
${message} - The formatted log message.
${ndc} - Nested Diagnostics Context - a thread-local structure.
${ndlc} - Async Nested Diagnostics Context - a thread-local structure.
${newline} - A newline literal.
${nlogdir} - The directory where NLog.dll is located.
${performancecounter} - The performance counter.
${processid} - The identifier of the current process.
${processinfo} - The information about the running process.
${processname} - The name of the current process.
${processtime} - The process time in format HH:mm:ss.mmm.
${qpc} - High precision timer, based on the value returned from QueryPerformanceCounter() optionally converted to seconds.
${registry} - A value from the Registry.
${shortdate} - The short date in a sortable format yyyy-MM-dd.
${sl-appinfo} - Information about Silverlight application.
${specialfolder} - System special folder path (includes My Documents, My Music, Program Files, Desktop, and more).
${stacktrace} - Stack trace renderer.
${tempdir} - A temporary directory.
${threadid} - The identifier of the current thread.
${threadname} - The name of the current thread.
${ticks} - The Ticks value of current date and time.
${time} - The time in a 24-hour, sortable format HH:mm:ss.mmm.
${var} - Render variable (new in 4.1)
${windows-identity} - Thread Windows identity information (username).
https://github.com/nlog/nlog/wiki/Layout-Renderers
EDIT
After a little more research, a good candidate is the garbage collector property called TotalMemory, which can be used in NLOG like this ${gc} (or %{gc:property=TotalMemory}). I'm using it and seeing the memory consumption skyrocketing, however the original question remains.