Skip copying jfr recoding into a temporary file #1242
Conversation
| ### What about this escape hatch? | ||
|
|
||
| If the escape hatch becomes active, it will log with `com.splunk.opentelemetry.profiler.RecordingEscapeHatch` | ||
| (you can grep for this in the logs). You may also look for `"** THIS WILL RESULT IN LOSS OF PROFILING DATA **"` | ||
| as a big hint that things are not well. | ||
|
|
||
| You may need to free up some disk space and/or give the JVM more resources. | ||
|
|
There was a problem hiding this comment.
@laurit @breedx-splk So this is gone? If that's the case, I'll remove it from the official troubleshooting.
There was a problem hiding this comment.
Current text:
Loss of profiling data or gaps in profiling data
-------------------------------------------------------------
If there are less than 100 megabytes of space available for the Java Virtual Machine, AlwaysOn Profiling activates the recording escape hatch, which appears in the logs as ``com.splunk.opentelemetry.profiler.RecordingEscapeHatch``. The escape hatch drops all logs with profiling data until more space is available.
To avoid the loss of profiling data due to the escape hatch, provide enough resources to the JVM.
|
Oh I think I had missed that we were doing that copy in the first place. Seems like a good idea to prevent that if we can. I'm not sure why this change also removes support for the escape hatch. Shouldn't we still use that? We don't want to fill up the disk. |
As we are not copying the recording to a file there is no need to check for free space. As for backlogged check I suspect it didn't work as these files were processed one at a time, previous one was deleted before the next was written do disk. |
Ah ok, I hadn't realized that we're not writing to disk at ALL now in the normal flow. I had assumed that the recordings were still to disk, but I do see that we I suppose there is chance that we could fill up the disk with the keepfiles setting, but I'm also ok with that since it's only really for development/testing purposes anyway. |
|
Roger! The troubleshooting section on the escape hatch has been removed now.
…On Fri, May 5, 2023 at 10:55 PM jason plumb ***@***.***> wrote:
[ External sender. Exercise caution. ]
I'm not sure why this change also removes support for the escape hatch.
Shouldn't we still use that? We don't want to fill up the disk.
As we are not copying the recording to a file there is no need to check
for free space. As for backlogged check I suspect it didn't work as these
files were processed one at a time, previous one was deleted before the
next was written do disk.
Ah ok, I hadn't realized that we're not writing to disk at ALL now in the
normal flow. I had assumed that the recordings were still to disk, but I do
see that we setToDisk(false) in start(). Seems good to me.
I suppose there is chance that we could fill up the disk with the
keepfiles setting, but I'm also ok with that since it's only really for
development/testing purposes anyway.
—
Reply to this email directly, view it on GitHub
<#1242 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANRAMCLJCTZ3KYFGL6HNBLXEVSNTANCNFSM6AAAAAAXSXOS7I>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
No description provided.