Frederic Branczyk
Frederic Branczyk
Whops nice catch. Yeah, I agree we should use the same synchronization techniques, and maybe more importantly, actually read from object storage if we have the debuginfos there already :D
(sorry mistakenly closed the issue, reopened immediately)
Thank you very much for reporting! Are both of these collected from the HTTP endpoints or is the Parca one from the Parca Agent?
Since this is not incorrect in the downloaded version, I suspect this is just a mistake in rendering inlined functions in the icicle graph in the wrong order.
hmm ... it seems like that already does the right thing https://github.com/parca-dev/parca/blob/790294ac3518c6edacc68645b3e678b626a6caff/pkg/query/flamegraph.go#L287-L301 Which makes it seem like either this is about asynchronous symbolization or the profile that was written was...
@yquansah do you have a suggestion of what we could do to make this clearer in our documentation? Maybe we should call this out more explicitly elsewhere?
Thank you so much for the issue @wiardvanrij! To be honest, we didn't really anticipate people using Parca from mobile so soon, so thank you very much for bringing it...
Agreed. We should start the http server basically immediately.
Maybe we can move the tsdb opening into a tsdb-opener function that we just pass and not block on.
The race in the logs looks like what we fixed in this one https://github.com/polarsignals/frostdb/pull/96 We should update frostdb and try again.