JVM 프로세스에서 정기적 인 스레드 덤프를 사용하여 문제가 발생할 경우 나중에 분석 할 수있는 시스템을 구축하려고합니다. 스레드 덤프를 사용하는 동안 JVM에 최소한의 오버 헤드가 발생합니다. 스레드 덤프를 가져 오는 방법은 여러 가지가 있으며 마침내 사용자 정의 JVMTI 에이전트를 작성하거나 ThreadMXBean을 사용하여 두 가지 옵션을 단축 목록에 추가했습니다. 누군가 JVM 오버 헤드를 줄이기위한 접근 방법에 대한 분석을 수행했는지 궁금합니다. 아니면 같은 오버 헤드가 발생합니까?JVM에서주기적인 스레드 덤프 - ThreadMXBean 대 JVMTI 에이전트
원하는 샘플링 빈도에 따라 다르지만 대부분의 경우 영향을 미치고 결과에 편향이 발생합니다. 그래도 JVMTI를 사용한다면 정직한 프로파일 러를 살펴 보자. https://github.com/RichardWarburton/honest-profiler
감사합니다. 안전한 지점과 AsyncGetCallTrace에 대해 알아두면 좋습니다. 이것은 나의 연구에 매우 유용 할 것이다. – Aniket
'AsyncGetCallTrace'가 프로파일 링에 좋습니다. 그러나 스레드 덤프는 작성하지 않습니다. 나는. AsyncGetCallTrace는 ** 활성 ** 스레드의 좋은 추적을 얻을 수 있지만 모든 스레드의 그림을 제공하지는 않습니다. – apangin
동의. 필자의 유스 케이스는 대부분 특정 스레드에서 모든 스레드가 수행중인 작업을 파악하는 것이 아니라 프로파일 링 필요성에 대한 것입니다. – Aniket
'ThreadMXBean'은 스레드 덤프를 얻는 가장 나쁜 방법이다. 스택 추적의 Java 수준 표현을 작성하므로 느려지고 힙에 많은 쓰레기가 생성됩니다. JVMTI는 더 나은 방법입니다. 그러나 JVM에 스택 추적을 요청하는 것이 더 좋습니다 (링크 된 답변 참조). – apangin
질문을 연결해 주셔서 감사합니다. JVM에 묻는 것은 내 (프로파일 링) 유스 케이스에서 요구되지 않는 안전한 지점에 대한 waitibg을 의미합니다. 실제로 perf 도구 나 DTrace를 사용하기 시작했습니다. – Aniket
스택 추적의 주된 목적이 CPU 프로파일 링이라면 질문의 말을 바꾸고 싶을 것입니다. 현재의 형태에서 질문은 실제로 이미 대답되었습니다. – apangin