temporary debugging aid #1192
temporary debugging aid #1192
Conversation
The previous setting never worked for me.
Setting it to automatic, as the error message suggested, works when I'm
deploying locally.
If this works for others & for our fastlane / release process, it would be
really convenient.
| @@ -444,11 +444,9 @@ | |||
| CLANG_ENABLE_MODULES = YES; | |||
| CODE_SIGN_ENTITLEMENTS = Runner/Runner.entitlements; | |||
| CODE_SIGN_IDENTITY = "Apple Development"; | |||
| "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution"; | |||
| CODE_SIGN_STYLE = Manual; | |||
| CODE_SIGN_STYLE = Automatic; | |||
There was a problem hiding this comment.
have you read the description of this PR? it's just a draft for aiding debugging of the problem we're having 🙃 none of it gets in.
There was a problem hiding this comment.
I have changed the name of the PR to make it less ambiguous, I realised that it would have helped to filter out the PR before you jumped into it.
| let frequency = Duration::from_secs(5); | ||
| runtime.spawn(async move { | ||
| for metrics in runtime_monitor.intervals() { | ||
| tracing::debug!(?metrics, "tokio metrics"); |
There was a problem hiding this comment.
What's the idea of how to use these metrics?
There was a problem hiding this comment.
it tells you all the information about the current runtime - descriptions of the metrics are here:
https://docs.rs/crate/tokio-metrics/latest
one of the most interesting for us are for example:
- workers_count - how many worker threads we actually have on our runtime (e.g. I was surprised seeing my iphone having 6!)
- https://docs.rs/tokio-metrics/0.2.*/tokio_metrics/struct.RuntimeMetrics.html#structfield.max_busy_duration - maximum amount the worker thread was busy.
also, if the queue of tasks scheduled but not executed would be growing we could see some contention with things falling behind.
also:task metrics might be interesting too.
There was a problem hiding this comment.
maximum amount the worker thread was busy
Interesting, does this include blocking threads?
Regardless, it will be good to make sure we aren't accidentally doing blocking work on the runtime!
That being said, there are a lot of them, so we might want to only log some subset of them every 5s, and then a more detailed view e.g once every 30min-1h? Just thinking of the tracing catastrophe I accidentally caused 😅
There was a problem hiding this comment.
this is not intended to be merged; I have now made it clear by renaming the PR!
this is more of a showcase of another tool that one can have on their side branch.
klochowicz
changed the title
This is purely for debugging. we might add it with some dart-define flag afterwards, but I didn't bother cleaning this whilst we're still bug hunting