Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
use HTTP to enable jemalloc profile #4600
What have you changed? (mandatory)
What are the type of the changes? (mandatory)
How has this PR been tested? (mandatory)
I have tested it manually. Some unit tests will be added later.
STATUS_SERVER above is the address of status_server and tikv-server is binary file path of
Does this PR affect documentation (docs) or release note? (mandatory)
No. I didn't find docs related to status_server. Maybe a new document for status_server is needed.
Does this PR affect tidb-ansible update? (mandatory)
Refer to a related PR or issue link (optional)
@BusyJay Jemalloc only has a global profiler, so now it cannot handle two requests at the same time ( one of them may be cut halfway because the profiler may have been closed ). I can add an Mutex to guarantee only one request is profiling. The request coming late will wait until previous one has finished. (Add a guard to start and stop profiler automatically)
brson left a comment •
I did leave a number of requests inline, and I have a few more general comments.
Please remove the existing code in
This code uses the existing
I know that's not your code, but the changes should be made so please do so.
The second resolution of the API seems like it might be too course. A second is a long time to a CPU. Milliseconds might be more appropriate. Not sure. Opinions @BusyJay?
More speculatively, HTTP can time out, and it's not obvious what the interaction here is between the API and HTTP timeouts. Fortunately all the resources here are closed on drop, so e.g. the profile won't be left turned on. The API as is may preclude profiling for an extended time because the request will time out.
The mutex around the profile request is not great, but for now I think it's fine, since this is a debugging tool. A more robust solution would simply extend the profiling duration while honoring the timeouts of each
seem it is not convenient to pass this env at runtime. can we set
But we should ensure setting
Yes it is technically possible. See the "tuning" section here. I don't know how complex it is to feed that configuration down through the various intermediary crates all the way to the jemalloc build system. I don't know if it will add additional overhead beyond what --enable-profiling does, but I suspect if it does it's mostly memory overhead, not instruction overhead, since it's a run-time option.
It looks to me like the most viable way to set "opt.prof" automatically is to create a statically initialized extern c-string,
I don't think we necessarily have to solve that problem in this PR though.
@YangKeao sorry for the long delay's here. I've given it a quick re-review and I think it is ok. Even if not, it's way off any critical path so any lingering bugs aren't a major problem.
I'm ok with merging, as long as we file a bug for the follow up to figure out how to set
Let's see what @siddontang says though.