Skip to content

Conversation

@hubgeter
Copy link
Contributor

@hubgeter hubgeter commented Nov 18, 2024

What problem does this PR solve?

fix jvm metrics memory leak.before pr #42507

when you set enable_jvm_monitor=true in be.conf, you can find that be jvm memory is slowly growing.
By analyzing the hprof file, we can find that there are a large number of java.lang.management.ThreadInfo objects.
The specific cause of the memory leak is: jni does not manually delete the local reference after getting the object from the array, resulting in the object not being GC.

Issue Number: close #xxx

Related PR: #44311

Problem Summary:

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
        just fix memory leak no logic has been changed
  • Behavior changed:

    • No.
    • Yes.
  • Does this need documentation?

    • No.
    • Yes.

Check List (For Reviewer who merge this PR)

  • Confirm the release note
  • Confirm test cases
  • Confirm document
  • Add branch pick label

@doris-robot
Copy link

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hubgeter
Copy link
Contributor Author

run buildall

@github-actions
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

jvm_metrics->jvm_thread_count->set_value(threadCount < 0 ? 0 : threadCount);

for (int i = 0; i < threadCount; i++) {
JNI_CALL_METHOD_CHECK_EXCEPTION(jobject, threadInfo, env,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not fix branch master at first, then auto pick to 3.0 and 2.1 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for version 3.0.3

Copy link
Contributor

Choose a reason for hiding this comment

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

Why only 3.0 have this problem? It seems line 488 is the same in branch master & 2.1

Copy link
Contributor

Choose a reason for hiding this comment

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

will pick to all branches.

@hubgeter
Copy link
Contributor Author

run buildall

@github-actions
Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@morningman morningman merged commit 486fb5b into apache:branch-3.0 Nov 19, 2024
hubgeter added a commit to hubgeter/doris that referenced this pull request Nov 20, 2024
### What problem does this PR solve?
fix jvm metrics memory leak.before pr apache#42507

when you set `enable_jvm_monitor=true` in be.conf, you can find that be
jvm memory is slowly growing.
By analyzing the hprof file, we can find that there are a large number
of `java.lang.management.ThreadInfo` objects.
The specific cause of the memory leak is: jni does not manually delete
the local reference after getting the object from the array, resulting
in the object not being GC.
@hubgeter hubgeter changed the title [fix](jvm)fix jvm metrics memory leak. [fix](jvm)fix jvm metrics memory leak.(#44311) Nov 20, 2024
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.

4 participants