-
Notifications
You must be signed in to change notification settings - Fork 436
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
DPL: disable cpu_usage_fraction for proxies #12976
Conversation
REQUEST FOR PRODUCTION RELEASES:
This will add The following labels are available |
// because of the rate limiting which biases the measurement. | ||
auto& spec = services.get<DeviceSpec const>(); | ||
bool enableCPUUsageFraction = true; | ||
if (spec.name.find("proxy") == std::string::npos) { |
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 think this will find all process with proxy in the name, I'd like to change it to affect only input proxies for now.
@ktf : I had a closer look, and I really don't like using the name for such things. Particularly, since the name is user-defined for the proxies. This will:
I think we should use some kind of flag / label mechanism for such purposes. I know that DPL already supports labels somehow. Could we make it such, that the ExternalFairMQDevice proxy sets a label "input-proxy", and we check for that label? Alternatively, as a simple solution we could add a bitmask to Whatever you prefer, but I'd prefer to go directly with a proper solution, not with such a hack. That said, in DPL there are many places where we do string comparison with the devicespec name, which I don't like. Perhaps we should generally transition that to a flag/label mechanism. I'll open a JIRA for this. |
We actually have labels which we could use, which we can require to fully match. I am happy to go that way, instead, but we need to agree on what the label is ("input-proxy"?). |
For me it is fine to use "input-proxy". Although, I have to say, I would actually prefer to have a bitmask for dpl-internal properties / labels, like "dpl-internal", "input-proxy", "output-proxy", "dummy-sink", "ccdb-backend", to avoid the string compares needed for matching the labels. Then we can switch also the existing string compares we have for these cases to just checking the bitmask. |
yes, we can use the bitmask/ enum at the DeviceSpec level, however at the dataprocessorspec level i would prefer to use the labels in order to avoid some extra json handling for the enums (dataprocessorspecs need to be json serialised). |
On a second look, on this specific case, we do not need the enum. The check is done on init and what it does is to enable / disable the metric, so there is no string comparison while in Running. I will expose a bitmask with the proxy / whatever information in the DataProcessingContext, but it does not need to be done in this particular PR. |
DPL: disable cpu_usage_fraction for proxies