Skip to content
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

Allow dynamic update of agent parameters #45

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

amuraru
Copy link

@amuraru amuraru commented Apr 18, 2019

Made the agent profilers re-entrant allowing
to attach and update profiling parameters at runtime

This is useful when the VM is not started with the agent
but can be later attached and controlled, e.g:

  • update profiling interval
  • enabling/disabling profilers

For time being only profilers parameters can be updated.
Transformers, reporter not

@CLAassistant
Copy link

CLAassistant commented Apr 18, 2019

CLA assistant check
All committers have signed the CLA.

@amuraru amuraru force-pushed the reentrant_profilers branch from 70d1eb0 to 1bdcde7 Compare April 18, 2019 07:44
@felixcheung felixcheung requested a review from hiboyang April 20, 2019 02:50
@@ -27,6 +28,7 @@

private final Profiler profiler;
private final AtomicLong errorCounter = new AtomicLong(0);
private ScheduledFuture<?> handler;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "handler" field is only used by setter/getter. Kind of weird. Any reason add it here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed to allow the the profilers to be "rescheduled" in the Agent, that is - cancel the previous registration and start a new one if profiling frequency changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not see your code invoke setHandler/getHandler. Maybe I miss something?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AgentImpl#scheduleProfilers calls both

Copy link
Contributor

@hiboyang hiboyang Apr 25, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sorry I missed that previously. It is still weird that we only have setHandler/getHandler in this class. Looks like we should move the "handler" out of this class?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok - refactored this even more and actually get rid of the ProfilerRunner altogether.
Made the Profiler itself Runnable.

import com.uber.profiling.util.NetworkUtils;
import com.uber.profiling.util.ProcFileUtils;
import com.uber.profiling.util.ProcessUtils;
import com.uber.profiling.util.SparkUtils;

import java.util.UUID;

public class ProcessInfoBase {
public abstract class ProcessInfoBase extends Profiler {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The semantic for class inheritance is establishing "is-a" relationship, see here. ProcessInfoBase should not be a Profiler.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as part of this change, all classes from com.uber.profiling.profilers are now profilers.

Agree that ProcessInfoBase extends Profiler seems forced naming wise, but if you look for example at ProcessInfoProfiler extends ProcessInfoBase there is a profiler eventually extending base Profiler

So my suggestion would be to ProcessInfoBase to ProcessInfoBaseProfiler.
Would it make sense then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the old code "ProcessInfoProfiler extends ProcessInfoBase" looks not good as well. Let me do some refactor there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the code to rename ProcessInfoBase to ProfilerBase, which makes more sense now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok - rebased on top of master


public abstract void profile();

void setRunner(ProfilerRunner runner){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding setRunner/getRunner here makes Profiler depends on ProfilerRunner, but it should not depend on it. Would suggest removing setRunner/getRunner here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. Don't like that as well :)
Thinking of it - would it make sense to actually have the ProfilerRunner an inner class in the base Profiler abstract class or even better make the Profiler base class Runnable so it can be:

  1. run once OR
  2. scheduled
    depending on the Profiler type

Again, my whole idea here is to make all profilers runnable (and hence cover both one-time and scheduled types).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I do not see your code call setRunner/getRunner though. Still prefer profiler not depending on this runner.

Copy link
Contributor

@hiboyang hiboyang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the code change here. It is usefully to support "attaching agent". I added several comments though.

@amuraru amuraru force-pushed the reentrant_profilers branch 2 times, most recently from 416a4df to 5dd6680 Compare April 23, 2019 20:59
@amuraru amuraru force-pushed the reentrant_profilers branch from 5dd6680 to 5b9e9ce Compare May 2, 2019 09:58
Made the agent profilers re-entrant allowing
to attach and update profiling parameters at runtime

This is useful when the VM is not started with the agent
but can be later attached and controlled, e.g:
- update profiling interval
- enabling/disabling profilers

For time being only profilers parameters can be updated.
Transformers, reporter not
@amuraru amuraru force-pushed the reentrant_profilers branch from 5b9e9ce to d5b0ade Compare May 2, 2019 10:00

void setReporter(Reporter reporter);
public abstract class Profiler implements Runnable {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Profiler now is a Runnable so it can be:

  • either run one-off if it's not scheduled run periodically
  • or, scheduled to run periodically

}
}

public ScheduledFuture<?> getScheduleHandler() {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is needed so we can reschedule the profiler when the scheduling interval is updated at runtime

for (Profiler profiler : profilers.values()) {
if (profiler.getScheduleHandler() != null) {
//cancel previous task if already scheduled
profiler.getScheduleHandler().cancel(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest removing getScheduleHandler() method and hide the logic of this cancelling inside the profiler. e.g.

if (profiler.isRunning()) {
profiler.cancel()
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good call - updated

@amuraru
Copy link
Author

amuraru commented May 29, 2019

@boy-uber is this something you wanna integrate? Tx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants