-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log memory usage of the agent and the mapper #2693
Log memory usage of the agent and the mapper #2693
Conversation
Codecov ReportAttention:
Additional details and impacted files
|
Robot Results
|
4b0a41d
to
549d6ec
Compare
@@ -56,6 +56,7 @@ c8y_http_proxy = { path = "crates/extensions/c8y_http_proxy" } | |||
c8y_log_manager = { path = "crates/extensions/c8y_log_manager" } | |||
c8y_mapper_ext = { path = "crates/extensions/c8y_mapper_ext" } | |||
camino = "1.1" | |||
cap = "0.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side commentary: Came across this sysinfo crate that covers a lot more parameters like CPU usage. Something we can consider in the future, for advanced monitoring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose is different. Sysinfo observes the operating system, while here the point is to monitor the amount of memory actually allocated by tedge on the heap.
crates/core/tedge_agent/src/lib.rs
Outdated
|
||
/// Interval at which the memory usage is logged (in seconds) | ||
#[clap(long = "log-memory-interval", default_value = "60")] | ||
pub log_memory_interval: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a short term addition or something permanent? If permanent, any specific reason why this is a command-line argument and not tedge config setting (other than convenience and simplicity)? No objections here, but just trying to understand the rationale behind that choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to set this right when the process starts - ideally before any thin-edge processing.
I see this as a new feature. This can possibly be extended with:
- the number of threads (currently we use the default i.e one thread per core),
- a cap on allocated memory (crashing if the process starts to go wild).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supporting a config would make it easier to enable on devices under test...as adding a flag is more difficult as we would need to use systemctl edit ...
to enable this feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will give a try to a config setting. This is definitely more convenient. However, not so straightforward to implement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supporting a config would make it easier to enable on devices under test...as adding a flag is more difficult as we would need to use
systemctl edit ...
to enable this feature.
Done with 4d19e41
The new setting is run.log_memory_interval
with a default of 5 minutes.
|
||
#[tokio::main] | ||
async fn main() -> Result<(), anyhow::Error> { | ||
async fn main() -> anyhow::Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to consider deprecating this main
and enforcing the use of a tedge -agent
as a symlink to tedge
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a ticket for that: #2696
let tedge_config = tedge_config::load_tedge_config(&opt.config_dir)?; | ||
block_on_with( | ||
tedge_config.run.log_memory_interval.duration(), | ||
tedge_mapper::run(opt), | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not very happy with that, i.e. loading the config without passing it to tedge_mapper::run()
.
Doing so is not straightforward as each of the actors used by the mapper and the agent have specific way to load the config, with or without a reference to the config-dir and other weirdness including duplicated paths to the same setting. It would be good to simplify all that in a follow up PR.
The default interval is of 60 seconds. This can be changed using the --log-memory-interval flag which sets the logging interval in seconds. ``` $ target/debug/tedge-mapper --log-memory-interval 5 c8y $ sudo target/debug/tedge-agent --log-memory-interval 5 ``` Signed-off-by: Didier Wenzek <[email protected]>
4d19e41
to
e783cfb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
Proposed changes
Log memory usage of the agent and the mapper.
The default interval is of 60 seconds.
This can be changed using the
--log-memory-interval
flag which sets the logging interval in seconds.Types of changes
Paste Link to the issue
#2692 (comment)
Checklist
cargo fmt
as mentioned in CODING_GUIDELINEScargo clippy
as mentioned in CODING_GUIDELINESFurther comments