JVM을 프로파일링하려면 JProfiler의 프로파일링 에이전트를 JVM에 로드해야 합니다. 이는 두 가지 방법으로 수행할 수 있습니다.
시작 스크립트에 -agentpath VM 파라미터를 지정하거나, attach API를 사용하여 이미 실행 중인 JVM에 에이전트를 로드하는 것입니다.
JProfiler는 두 모드를 모두 지원합니다. VM 파라미터를 추가하는 것이 프로파일링 시 권장되는 방식이며, 통합 마법사, IDE 플러그인 및 JProfiler 내에서 JVM을 시작하는 세션 구성에서 사용됩니다. Attach는 로컬뿐만 아니라 SSH를 통한 원격에서도 작동합니다.
-agentpath VM 파라미터
프로파일링 에이전트를 로드하는 VM 파라미터가 어떻게 구성되는지 이해하면 유용합니다. -agentpath는
JVMTI 인터페이스를 사용하는 모든 종류의 네이티브 라이브러리를 로드하기 위해 JVM에서 제공하는 범용 VM 파라미터입니다.
프로파일링 인터페이스인 JVMTI는 네이티브 인터페이스이므로, 프로파일링 에이전트는 네이티브 라이브러리여야 합니다. 즉,
명시적으로 지원되는 플랫폼에서만 프로파일링할 수 있습니다.
32비트 및 64비트 JVM에도 서로 다른 네이티브 라이브러리가 필요합니다.
반면 Java 에이전트는 -javaagent VM 파라미터로 로드되며 제한된 기능 세트에만 접근할 수 있습니다.
-agentpath: 뒤에는 네이티브 라이브러리의 전체 경로 이름이 추가됩니다. 플랫폼별 라이브러리 이름만 지정하는
동등한 파라미터 -agentlib:도 있지만, 이 경우 해당 라이브러리가 라이브러리 경로에 포함되어 있는지 확인해야 합니다.
라이브러리 경로 뒤에 등호(=)를 추가하고 쉼표로 구분하여 에이전트에 옵션을 전달할 수 있습니다. 예를 들어 Linux에서는
전체 파라미터가 다음과 같이 표시될 수 있습니다.
-agentpath:/opt/jprofiler16/bin/linux-x64/libjprofilerti.so=port=8849,nowait
첫 번째 등호는 경로 이름과 파라미터를 구분하고, 두 번째 등호는 port=8849 파라미터의 일부입니다.
이 공통 파라미터는 프로파일링 에이전트가 JProfiler GUI의 연결을 수신 대기하는 포트를 정의합니다. 8849는
실제 기본 포트이므로 이 파라미터를 생략할 수도 있습니다. 하지만 동일한 머신에서 여러 JVM을 프로파일링하려면
서로 다른 포트를 할당해야 합니다. IDE 플러그인과 로컬에서 시작된 세션은 이 포트를 자동으로 할당하지만,
통합 마법사의 경우 포트를 명시적으로 선택해야 합니다.
두 번째 파라미터인 nowait는 프로파일링 에이전트가 시작 시 JVM을 차단하고 JProfiler GUI가 연결될 때까지
기다리지 않도록 지시합니다. 시작 시 차단하는 것이 기본 동작인데, 프로파일링 에이전트가 커맨드 라인 파라미터가 아니라
JProfiler GUI 또는 설정 파일에서 프로파일링 설정을 수신하기 때문입니다. 커맨드 라인 파라미터는 프로파일링 에이전트를
부트스트랩하고 시작 방법을 알리며 디버그 플래그를 전달하기 위한 용도로만 사용됩니다.
경우에 따라 시작 시 프로파일링 설정 적용이 필요하며, 이를 달성하기 위해 일부 수동 작업이 필요할 수 있습니다.
기본적으로 JProfiler 에이전트는 통신 socket을 루프백 인터페이스에 바인딩합니다. 특정 인터페이스를 선택하기 위해
address=[IP address] 옵션을 추가하거나, 사용 가능한 모든 네트워크 인터페이스에 통신 socket을 바인딩하기 위해
address=0.0.0.0을 추가할 수 있습니다. 이는 Docker 컨테이너에서 프로파일링 포트를 외부에 게시하려는 경우
필요할 수 있습니다.
로컬에서 시작된 세션
IDE의 "실행 구성(Run configurations)"과 마찬가지로, 로컬에서 시작되는 세션을 JProfiler에서 직접 구성할 수 있습니다. 클래스패스, 메인 클래스, 작업 디렉터리, VM 파라미터 및 인수를 지정하면 JProfiler가 세션을 대신 시작합니다. JProfiler와 함께 제공되는 모든 데모 세션은 로컬에서 시작되는 세션입니다.
특별한 실행 모드로 "Web Start"가 있으며, 여기서 JNLP 파일의 URL을 선택하면 JProfiler가 이를 프로파일링하기 위한 JVM을 시작합니다. 이 기능은 OpenWebStart를 지원하며, Java 9 이전 Oracle JRE의 레거시 WebStart는 지원되지 않습니다.
로컬에서 시작된 세션은 메인 메뉴에서 Session→Conversion Wizards를 호출하여 변환 마법사를 통해
독립 실행형(standalone) 세션으로 변환할 수 있습니다. Convert Application Session to Remote는 단순히
시작 스크립트를 생성하고 Java 호출에 -agentpath VM 파라미터를 삽입합니다.
Convert Application Session to Offline는 오프라인 프로파일링을 위한
시작 스크립트를 생성하며, 이는 시작 시 설정이 로드되고 JProfiler GUI가 필요하지 않음을 의미합니다.
Convert Application Session to Redistributed Session도 동일한 작업을 수행하지만, 그 옆에
프로파일링 에이전트와 설정 파일이 포함된 jprofiler_redist 디렉터리를 생성하여 JProfiler가 설치되지 않은
다른 머신으로 전달할 수 있도록 합니다.
프로파일된 애플리케이션을 직접 개발하는 경우, 시작 세션 대신 IDE 통합을 사용하는 것을 고려해 보십시오. 훨씬 편리하며 더 나은 소스 코드 탐색 기능을 제공합니다. 애플리케이션을 직접 개발하지 않지만 이미 시작 스크립트가 있는 경우에는 원격 통합 마법사를 사용하는 것을 고려해 보십시오. Java 호출에 추가해야 하는 정확한 VM 파라미터를 알려줍니다.
통합 마법사
JProfiler의 통합 마법사는 추가 VM 파라미터를 포함하도록 프로그래밍 방식으로 수정할 수 있는 시작 스크립트나 설정 파일을 통해 잘 알려진 여러 서드파티 컨테이너를 처리합니다. 일부 제품의 경우, VM 파라미터가 인수나 환경 변수를 통해 전달되는 시작 스크립트를 생성할 수 있습니다.
모든 경우에 JProfiler가 수정을 수행하는 데 필요한 컨텍스트를 가질 수 있도록 서드파티 제품에서 특정 파일을 찾아야 합니다. 일부 범용 마법사는 프로파일링을 활성화하기 위해 수행해야 하는 작업에 대한 지침만 제공합니다.
각 통합 마법사의 첫 번째 단계는 로컬 머신에서 프로파일링할지 원격 머신에서 프로파일링할지 선택하는 것입니다. 로컬 머신의 경우 JProfiler가 플랫폼, JProfiler 설치 위치 및 설정 파일 위치를 이미 알고 있으므로 더 적은 정보를 제공해도 됩니다.
중요한 결정 사항은 위에서 설명한 "시작 모드"입니다. 기본적으로 프로파일링 설정은 시작 시 JProfiler UI에서 전송되지만, 프로파일링 에이전트에 JVM을 즉시 시작하도록 지시할 수도 있습니다. 후자의 경우 JProfiler GUI가 연결되면 프로파일링 설정을 적용할 수 있습니다.
하지만 프로파일링 설정이 포함된 설정 파일을 지정할 수도 있으며, 이는 훨씬 더 효율적입니다. 이 작업은 Config synchronization 단계에서 수행됩니다. 이 경우의 주된 문제는 로컬에서 프로파일링 설정을 편집할 때마다 원격 측과 설정 파일을 동기화해야 한다는 점입니다. 가장 깔끔한 방법은 Remote address 단계에서 SSH를 통해 원격 머신에 연결하는 것이며, 그러면 SSH를 통해 설정 파일을 자동으로 전송할 수 있습니다.
통합 마법사가 끝나면 프로파일링을 시작하고, 일반적이지 않은(non-generic) 특화된 경우에는 애플리케이션 서버와 같은 서드파티 제품도 함께 시작하는 세션이 생성됩니다.
외부 시작 스크립트는 세션 구성 대화상자의 Application settings 탭에 있는 Execute start command 및 Execute stop command 옵션으로 처리되며, Open browser with URL 확인란을 선택하여 URL을 표시할 수 있습니다. 이곳은 원격 머신의 주소와 설정 동기화 옵션을 변경할 수 있는 위치이기도 합니다.
통합 마법사는 모두 프로파일된 JVM이 원격 머신에서 실행되는 경우를 처리합니다. 그러나 설정 파일이나 시작 스크립트를
수정해야 할 때는 이를 로컬 머신으로 복사한 후 수정된 버전을 다시 원격 머신으로 전송해야 합니다. 원격 머신에서 커맨드 라인
도구인 jpintegrate를 직접 실행하여 해당 위치에서 직접 수정하도록 하는 것이 더 편리할 수 있습니다.
jpintegrate는 JProfiler의 전체 설치가 필요하며 JProfiler GUI와 동일한 JRE 요구 사항을 갖습니다.
원격 프로파일링 세션을 시작하는 동안 오류가 발생하면, 문제를 해결하기 위해 취할 수 있는 조치 체크리스트가 포함된 문제 해결 가이드를 참조하십시오.
IDE 통합
애플리케이션을 프로파일링하는 가장 편리한 방법은 IDE 통합을 이용하는 것입니다. 개발 중 평소에 IDE에서 애플리케이션을 시작한다면, IDE에는 이미 필요한 모든 정보가 있으므로 JProfiler 플러그인이 프로파일링을 위한 VM 파라미터를 추가하고, 필요한 경우 JProfiler를 시작하며, 프로파일된 JVM을 JProfiler 메인 창에 연결하기만 하면 됩니다.
모든 IDE 통합은 JProfiler 설치 디렉터리의 integrations 디렉터리에 포함되어 있습니다. 원칙적으로 해당 디렉터리의
아카이브는 각 IDE의 플러그인 설치 메커니즘을 통해 수동으로 설치할 수 있습니다. 그러나 IDE 통합을 설치하는 권장 방법은
메인 메뉴에서 Session→IDE integrations를 호출하는 것입니다.
IDE에서 시작된 프로파일링 세션은 JProfiler에서 별도의 세션 항목을 갖지 않는데, 이러한 세션은 JProfiler GUI에서 시작할 수 없기 때문입니다. 프로파일링 설정은 IDE의 설정에 따라 프로젝트별 또는 실행 구성별로 유지됩니다.
IDE에 연결되면 JProfiler의 툴바에 윈도우 전환기가 표시되어 IDE의 연결된 창으로 쉽게 다시 이동할 수 있습니다. 모든 Show Source 액션은 이제 JProfiler의 기본 제공 소스 뷰어 대신 IDE에서 직접 소스를 표시합니다.
IDE 통합은 이후 장에서 자세히 다룹니다.
AI 에이전트를 위한 MCP 서버
JProfiler에는 Claude Code, Antigravity 또는 Junie와 같은 AI 코딩 에이전트가 JProfiler의 프로파일링 및 분석 기능을 사용할 수 있도록 지원하는 MCP 서버가 포함되어 있습니다. AI 에이전트는 Java 프로세스를 시작 및 프로파일링하고, 로컬에서 실행 중인 JVM 또는 Docker 컨테이너의 JVM에 attach하며, 힙 덤프를 생성하고 기존 스냅샷을 분석할 수 있습니다. MCP 통합은 메인 메뉴의 Session→AI Agent Integrations에서 설정합니다.
Attach 모드
JVM을 프로파일링할지 여부를 사전에 반드시 결정할 필요는 없습니다. JProfiler의 attach 기능을 사용하면 실행 중인 JVM을 선택하고 프로파일링 에이전트를 즉석에서 로드할 수 있습니다. Attach 모드는 편리하지만 알아두어야 할 몇 가지 단점이 있습니다:
- 실행 중인 JVM 목록에서 프로파일링하려는 JVM을 식별해야 합니다. 동일한 머신에서 여러 JVM이 실행 중인 경우 다소 까다로울 수 있습니다.
- 인스트루멘테이션을 추가하기 위해 잠재적으로 많은 클래스를 재정의해야 하므로 추가적인 오버헤드가 발생합니다.
- JProfiler의 일부 기능은 attach 모드에서 사용할 수 없습니다. 이는 주로 JVMTI의 일부 기능이 JVM이 초기화될 때만 켜질 수 있고 JVM 라이프사이클의 이후 단계에서는 사용할 수 없기 때문입니다.
- 일부 기능은 전체 클래스 중 상당 부분에 인스트루멘테이션을 적용해야 합니다. 클래스가 로드되는 동안 인스트루멘테이션을 수행하는 것은 비용이 적게 들지만, 클래스가 이미 로드된 후에 추가하는 것은 그렇지 않습니다. 따라서 attach 모드를 사용할 때는 이러한 기능이 기본적으로 비활성화됩니다.
-
Attach 기능은 OpenJDK JVM, 버전 6 이상의 Oracle JVM, 최신 OpenJ9 JVM(8u281+, 11.0.11+ 또는 Java 17+) 또는 해당 릴리스를 기반으로 하는
IBM JVM에서 지원됩니다. 해당 JVM에
-XX:+PerfDisableSharedMem및-XX:+DisableAttachMechanismVM 파라미터가 지정되어 있지 않아야 합니다.
JProfiler 시작 센터의 Quick Attach 탭에는 프로파일링할 수 있는 모든 JVM이 나열됩니다. 목록 항목의 배경색은 프로파일링 에이전트가 이미 로드되었는지, JProfiler GUI가 현재 연결되어 있는지, 아니면 오프라인 프로파일링이 구성되었는지를 나타냅니다.
프로파일링 세션을 시작할 때 세션 설정 대화상자에서 프로파일링 설정을 구성할 수 있습니다. 동일한 프로세스를 반복해서 프로파일링할 때 매번 동일한 구성을 다시 입력하고 싶지 않을 것이므로, 빠른 attach 기능으로 생성된 세션을 닫을 때 영구 세션으로 저장할 수 있습니다. 다음에 이 프로세스를 프로파일링할 때는 Quick Attach 탭 대신 Start Session 탭에서 저장된 세션을 시작하십시오. 여전히 실행 중인 JVM을 선택해야 하지만, 프로파일링 설정은 이전에 이미 구성한 것과 동일합니다.
로컬 서비스에 attach하기
JVM의 attach API는 호출 프로세스가 attach하려는 프로세스와 동일한 사용자로 실행되어야 하므로, JProfiler에 표시되는 JVM 목록은 현재 사용자로 제한됩니다. 다른 사용자가 시작한 프로세스는 대부분 서비스입니다. 서비스에 attach하는 방법은 Windows, Linux 및 Unix 기반 플랫폼에 따라 다릅니다.
Windows에서는 attach 대화상자에 로컬에서 실행 중인 모든 서비스를 나열하는 Show Services 버튼이 있습니다. JProfiler는 브리지 실행 파일을 실행하여 프로세스가 어떤 사용자로 실행 중이든 관계없이 해당 프로세스에 attach할 수 있도록 합니다.
Linux에서 JProfiler는 대부분의 Linux 배포판에 포함된 PolicyKit을 통해 UI에서 직접 사용자를 전환할 수 있도록 지원합니다. Attach 대화상자에서 Switch User를 클릭하면 다른 사용자 이름을 입력하고 시스템 비밀번호 대화상자를 통해 인증할 수 있습니다.
macOS를 포함한 Unix 기반 플랫폼에서는 Unix 변형 또는 Linux 배포판에 따라 su 또는 sudo를
사용하여 커맨드 라인 도구인 jpenable을 다른 사용자로 실행할 수 있습니다. macOS 및 Ubuntu와 같은
데비안 기반 Linux 배포판에서는 sudo가 사용됩니다.
sudo를 사용하는 경우 다음과 같이 호출합니다.
sudo -u userName jpenablesu를 사용하는 경우 필요한 커맨드 라인은 다음과 같습니다.
su userName -c jpenable
jpenable을 사용하면 JVM을 선택할 수 있으며 프로파일링 에이전트가 수신 대기 중인 포트를 알려줍니다.
그런 다음 JProfiler UI의 로컬 세션으로 연결하거나 jpenable에서 제공한 포트에 직접 연결하는 SSH 연결을 사용할 수 있습니다.
원격 머신의 JVM에 attach하기
프로파일링에서 가장 까다로운 환경은 원격 프로파일링입니다. 즉, JProfiler GUI는 로컬 머신에서 실행되고 프로파일된 JVM은 다른 머신에서 실행되는 경우입니다. 프로파일된 JVM에 -agentpath VM 파라미터를 전달하는 구성의 경우, 원격 머신에 JProfiler를 설치하고 로컬 머신에 원격 세션을 설정해야 합니다. JProfiler의 원격 attach 기능을 사용하면 이러한 수정이 필요하지 않습니다. 원격 머신에 로그인할 SSH 자격 증명만 있으면 됩니다.
SSH 연결을 통해 JProfiler는 "JProfiler 설치" 도움말 항목에서 설명한 에이전트 패키지를 업로드하고 포함된 커맨드 라인 도구를 원격 머신에서 실행할 수 있습니다. 로컬 머신에 SSH가 설정되어 있을 필요는 없으며, JProfiler 자체 구현체가 함께 제공됩니다. 가장 단순한 설정에서는 호스트, 사용자 이름 및 인증만 정의하면 됩니다.
SSH 연결을 사용하면 JProfiler가 실행 중인 JVM의 자동 검색을 수행하거나 프로파일링 에이전트가 이미 수신 대기 중인 특정 포트에
연결할 수 있습니다. 후자의 경우 위에서 설명한 대로 원격 머신에서 jpenable 또는 jpintegrate를
사용하여 프로파일링할 특수 JVM을 준비할 수 있습니다. 그런 다음 구성된 프로파일링 포트에 직접 연결하도록 SSH 원격 attach를 구성할 수 있습니다.
자동 검색은 SSH 로그인 사용자로 시작된 원격 머신의 모든 JVM을 나열합니다. 대부분의 경우 이는 프로파일링하려는 서비스를 시작한
사용자가 아닙니다. 서비스를 시작하는 사용자는 일반적으로 SSH 연결이 허용되지 않으므로, JProfiler는 sudo 또는
su를 사용하여 해당 사용자로 전환할 수 있는 Switch User 하이퍼링크를 제공합니다.
복잡한 네트워크 토폴로지에서는 때때로 원격 머신에 직접 연결할 수 없는 경우가 있습니다. 이 경우 GUI에서 멀티 홉(multi-hop) SSH 터널로 연결하도록 JProfiler에 지시할 수 있습니다. SSH 터널 끝에서 대개 "127.0.0.1"로 직접 네트워크 연결을 한 번 설정할 수 있습니다.
다른 인증 메커니즘의 경우 OpenSSH 터널 모드를 사용할 수 있습니다. OpenSSH 실행 파일을 사용할 때 커맨드 라인에 입력하는 것처럼 호스트 이름을 입력합니다. 이는 OpenSSH 설정 파일에 구성된 별칭(alias)일 수도 있습니다. 호스트 이름 외에 포트와 사용자 이름을 선택적으로 지정할 수 있습니다. Windows에서는 Microsoft의 내장 OpenSSH 클라이언트만 지원됩니다.
SSH options 텍스트 필드에는 커맨드 라인에서 지정할 수 있는 OpenSSH 실행 파일에 대한 임의의 추가 인수를 입력할 수 있습니다. 이는 예를 들어 AWS session manager를 통해 SSH 연결을 터널링하는 방법과 같이 튜토리얼에서 제공하는 지침을 따를 때 특히 유용합니다.
HPROF 스냅샷은 SSH 로그인 사용자로 시작된 JVM에 대해서만 가져올 수 있습니다. 이는 HPROF 스냅샷의 경우 JVM을 시작한 사용자의 접근 권한으로 기록되는 중간 파일이 필요하기 때문입니다. 보안상의 이유로 다운로드를 위해 파일 권한을 SSH 로그인 사용자에게 이전할 수 없습니다. 전체 프로파일링 세션에는 이러한 제한이 없습니다.
Docker 컨테이너에서 실행 중인 JVM에 attach하기
Docker 컨테이너에는 일반적으로 SSH 서버가 설치되어 있지 않으며, Docker 컨테이너에서 jpenable을 사용할 수는 있지만 Dockerfile에 지정하지 않는 한 외부에서 프로파일링 포트에 접근할 수 없습니다.
JProfiler에서는 빠른 attach 대화상자에서 Docker 컨테이너를 선택하여 Windows 또는 macOS의 로컬 Docker Desktop 설치에서
실행 중인 JVM에 attach할 수 있습니다. 기본적으로 JProfiler는 docker 실행 파일의 경로를 자동으로 감지합니다.
또는 일반 설정 대화상자의 "External Programs" 탭에서 구성할 수도 있습니다.
컨테이너를 선택하면 Docker 컨테이너 내부에서 실행 중인 모든 JVM이 표시됩니다. JVM을 선택하면 JProfiler는 Docker 명령을 사용하여 선택한 컨테이너에 프로파일링 에이전트를 자동으로 설치하고, 프로파일링을 위해 JVM을 준비하며, 프로파일링 프로토콜을 외부로 터널링합니다.
원격 Docker 설치 환경의 경우 SSH 원격 attach 기능을 사용한 다음 원격 머신에서 Docker 컨테이너를 선택할 수 있습니다. 로그인 사용자가 docker 그룹에 속해 있지 않은 경우 위에서 설명한 대로 먼저 사용자를 전환할 수 있습니다.
원격 attach 대화상자의 Select Container 하이퍼링크를 사용하여 실행 중인 Docker 컨테이너를 선택하고 그 안에서 실행 중인 모든 JVM을 표시할 수 있습니다.
Kubernetes 클러스터에서 실행 중인 JVM에 attach하기
Kubernetes 클러스터에서 실행 중인 JVM을 프로파일링하기 위해 JProfiler는 파드(pod) 및 컨테이너 검색뿐만 아니라 컨테이너 연결,
해당 JVM 목록 표시 및 최종적으로 선택한 JVM 연결을 위해 kubectl 커맨드 라인 도구를 사용합니다.
kubectl 커맨드 라인 도구는 로컬 컴퓨터 또는 SSH 접근이 가능한 원격 머신에서 사용할 수 있습니다.
JProfiler는 두 시나리오를 모두 직접 지원합니다. 로컬 설치의 경우 JProfiler는 kubectl 경로를
자동으로 감지하려고 시도하지만, 일반 설정 대화상자의 "External Programs" 탭에서 명시적 경로를 구성할 수 있습니다.
JProfiler는 감지된 모든 컨테이너를 3개 레벨의 트리로 나열합니다. 최상위에는 감지된 파드가 있는 하위 노드를 포함하는 네임스페이스 노드가 있습니다. 리프 노드는 컨테이너 자체이며, 실행 중인 JVM 선택으로 진행하려면 이 중 하나를 선택해야 합니다.
kubectl은 Kubernetes 클러스터에 연결하기 위해 인증을 위한 추가 커맨드 라인 옵션이 필요할 수 있습니다.
이러한 옵션은 컨테이너 선택 대화상자 상단에 입력할 수 있습니다. 이러한 옵션은 민감한 정보일 수 있으므로 재시작 시에도 기억하도록
확인란을 명시적으로 선택한 경우에만 디스크에 저장됩니다. 이 확인란의 선택을 취소하면 이전에 저장된 정보가 즉시 삭제됩니다.
실행 중인 JVM의 표시 이름 설정
JVM 선택 테이블에서 표시되는 프로세스 이름은 프로파일된 JVM의 메인 클래스와 해당 인수입니다. exe4j 또는 install4j에 의해 생성된 런처의 경우 실행 파일 이름이 표시됩니다.
그렇지 않으면 구별할 수 없는 동일한 메인 클래스를 가진 여러 프로세스가 있는 등의 이유로 표시되는 이름을 직접 설정하려면
VM 파라미터 -Djprofiler.displayName=[name]을 설정할 수 있습니다. 이름에 공백이 포함된 경우 작은따옴표를 사용하십시오:
-Djprofiler.displayName='My name with spaces'. 그리고 필요한 경우 전체 VM 파라미터를 큰따옴표로 묶으십시오.
-Djprofiler.displayName 외에도 JProfiler는 -Dvisualvm.display.name도 인식합니다.
