Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Per subsystem resource usage tracking #4198

Closed
drahnr opened this issue Nov 1, 2021 · 6 comments
Closed

Per subsystem resource usage tracking #4198

drahnr opened this issue Nov 1, 2021 · 6 comments
Assignees
Labels
T4-parachains_engineering This PR/Issue is related to Parachains performance, stability, maintenance.

Comments

@drahnr
Copy link
Contributor

drahnr commented Nov 1, 2021

Problem:

When we exhaust resources, we have currently little knowledge about which subsystem consumes how much CPU or memory.

Caveats:

We are fully async on the node side. Hence this cannot be done on a per thread/process level but must be more granular on the logical tasks level.

Hints:

  • jemalloc allows setting up multiple pools
  • extract cpu usage share from the executor in use
  • substrate has some primitives avail iirc, ask @tomaka - if insufficient, consider tokio-console or related
@ordian
Copy link
Member

ordian commented Nov 1, 2021

for CPU see Substrate Service Tasks dashboard, and metrics for spawned futures in
https://github.com/paritytech/substrate/blob/b674bd2338b645c41a7f2c21e696891c7e34500d/client/service/src/task_manager/mod.rs

@sandreim
Copy link
Contributor

sandreim commented Nov 9, 2021

We need to align on the subsystem/task name formatting. I propose to use snake_case for the subsystem/task name or even use SCREAMING_SNAKE_CASE for the subsystem name. IMO this makes it easier to read and stay consistent with variable, function, method, etc names in the codebase.

WDYT ? @drahnr @ordian @bkchr

@drahnr
Copy link
Contributor Author

drahnr commented Nov 9, 2021

snake_case sounds good to me.

@ordian
Copy link
Member

ordian commented Nov 9, 2021

I don't have a strong opinion as long as it's consistent :)

@sandreim
Copy link
Contributor

sandreim commented Nov 9, 2021

Discussed with @bkchr and he suggested we go for kebab-case as this is already the naming convention in use for most of the task names. So, it sounds reasonable to me and requires far less changes. Anyone have a strong opinion against kebab-case ? @drahnr @ordian

@sandreim
Copy link
Contributor

Per task memory usage turned out to be more complicated (#4299). Closing this for now ...

@ordian ordian added the T4-parachains_engineering This PR/Issue is related to Parachains performance, stability, maintenance. label Aug 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T4-parachains_engineering This PR/Issue is related to Parachains performance, stability, maintenance.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants