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의 "실행 설정"과 마찬가지로, JProfiler에서 직접 로컬에서 실행된 세션을 설정할 수 있습니다. 클래스패스, 메인 클래스, 작업 디렉토리, VM 파라미터 및 인수를 지정하면 JProfiler가 세션을 실행합니다. JProfiler와 함께 제공되는 모든 데모 세션은 로컬에서 실행된 세션입니다.
특별한 실행 모드로 "Web Start"가 있으며, JNLP 파일의 URL을 선택하면 JProfiler가 JVM을 실행하여 프로파일링합니다. 이 기능은 OpenWebStart를 지원하며, Java 9 이전 Oracle JRE의 레거시 WebStart는 지원되지 않습니다.
로컬에서 실행된 세션은 메인 메뉴에서 Session→Conversion Wizards를 실행하여
변환 마법사를 통해 독립 실행형 세션으로 변환할 수 있습니다.
Convert Application Session to Remote는 시작 스크립트를 생성하고
Java 호출에 -agentpath VM 파라미터를 삽입합니다.
Convert Application Session to Offline는 오프라인 프로파일링을 위한
시작 스크립트를 생성하며, 이는 시작 시 설정이 로드되고 JProfiler GUI가 필요하지 않음을 의미합니다.
Convert Application Session to Redistributed Session은 동일한 작업을 수행하지만,
JProfiler가 설치되지 않은 다른 머신에 배포할 수 있도록 프로파일링 에이전트와 설정 파일이 포함된
jprofiler_redist 디렉토리를 함께 생성합니다.
프로파일링 대상 애플리케이션을 직접 개발하는 경우, 실행된 세션 대신 IDE 통합을 사용하는 것을 고려하세요. 더 편리하고 소스 코드 탐색이 더 용이합니다. 애플리케이션을 직접 개발하지 않지만 이미 시작 스크립트가 있는 경우, 원격 통합 마법사를 사용하는 것을 고려하세요. Java 호출에 추가해야 할 정확한 VM 파라미터를 알려줍니다.
통합 마법사
JProfiler의 통합 마법사는 추가 VM 파라미터를 포함하도록 프로그래밍 방식으로 수정할 수 있는 시작 스크립트나 설정 파일을 가진 많은 잘 알려진 서드파티 컨테이너를 처리합니다. 일부 제품의 경우 VM 파라미터가 인수 또는 환경 변수를 통해 전달되는 시작 스크립트를 생성할 수 있습니다.
모든 경우에 서드파티 제품에서 특정 파일을 찾아야 하므로, JProfiler가 수정을 수행하는 데 필요한 컨텍스트를 확보할 수 있습니다. 일부 범용 마법사는 프로파일링을 활성화하기 위해 수행해야 할 작업에 대한 지침만 제공합니다.
각 통합 마법사의 첫 번째 단계는 로컬 머신에서 프로파일링할지 원격 머신에서 프로파일링할지 선택하는 것입니다. 로컬 머신의 경우 JProfiler가 이미 플랫폼, JProfiler 설치 위치 및 설정 파일 위치를 알고 있으므로 더 적은 정보를 제공하면 됩니다.
위에서 논의한 "시작 모드"가 중요한 결정 사항입니다. 기본적으로 프로파일링 설정은 시작 시 JProfiler UI에서 전송되지만, 프로파일링 에이전트가 JVM을 즉시 시작하도록 설정할 수도 있습니다. 후자의 경우 JProfiler GUI가 연결되면 프로파일링 설정을 적용할 수 있습니다.
그러나 프로파일링 설정이 포함된 설정 파일을 지정할 수도 있으며, 이 방법이 훨씬 더 효율적입니다. 이는 Config synchronization 단계에서 수행됩니다. 이 경우 주요 문제는 로컬에서 프로파일링 설정을 편집할 때마다 설정 파일을 원격 측과 동기화해야 한다는 것입니다. 가장 우아한 방법은 Remote address 단계에서 SSH를 통해 원격 머신에 연결하는 것으로, 그러면 설정 파일이 SSH를 통해 자동으로 전송될 수 있습니다.
통합 마법사가 끝나면 프로파일링을 시작하는 세션이 생성되며, 범용이 아닌 경우에는 애플리케이션 서버와 같은 서드파티 제품도 함께 시작됩니다.
외부 시작 스크립트는 세션 설정 대화상자의 Application settings 탭에 있는 Execute start script 및 Execute stop script 옵션으로 처리되며, 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 GUI에서 시작할 수 없으므로 JProfiler에 자체 세션 항목이 생성되지 않습니다. 프로파일링 설정은 IDE의 설정에 따라 프로젝트별 또는 실행 설정별로 저장됩니다.
IDE에 연결된 경우, JProfiler는 툴바에 창 전환기를 표시하여 IDE의 연결된 창으로 쉽게 돌아갈 수 있게 합니다. 모든 Show Source 동작은 이제 JProfiler의 내장 소스 뷰어 대신 IDE에서 직접 소스를 표시합니다.
IDE 통합은 이후 챕터에서 자세히 설명합니다.
AI 에이전트를 위한 MCP 서버
JProfiler에는 Claude Code, Gemini CLI 또는 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가 현재 연결되어 있는지, 또는 오프라인 프로파일링이 설정되었는지를 나타냅니다.
프로파일링 세션을 시작할 때 세션 설정 대화상자에서 프로파일링 설정을 구성할 수 있습니다. 동일한 프로세스를 반복적으로 프로파일링하는 경우 매번 동일한 설정을 다시 입력하고 싶지 않을 것이므로, quick 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와 같은 Debian 기반 Linux 배포판에서는 sudo를 사용합니다.
sudo를 사용하는 경우 다음과 같이 호출하세요:
sudo -u userName jpenablesu를 사용하는 경우 필요한 커맨드 라인은 다음과 같습니다:
su userName -c jpenable
jpenable은 JVM을 선택하고 프로파일링 에이전트가 수신 대기 중인 포트를 알려줍니다.
그 후 JProfiler UI에서 로컬 세션으로 연결하거나 jpenable이 제공한 포트에 직접 연결하는
SSH 연결을 사용할 수 있습니다.
원격 머신의 JVM에 Attach하기
프로파일링에서 가장 까다로운 설정은 원격 프로파일링입니다. JProfiler GUI는 로컬 머신에서 실행되고 프로파일링 대상 JVM은 다른 머신에서 실행됩니다. -agentpath VM 파라미터를 프로파일링 대상 JVM에 전달하는 설정의 경우, 원격 머신에 JProfiler를 설치하고 로컬 머신에 원격 세션을 설정해야 합니다. JProfiler의 원격 attach 기능을 사용하면 이러한 수정이 필요하지 않습니다. 원격 머신에 로그인하기 위한 SSH 자격 증명만 있으면 됩니다.
SSH 연결을 통해 JProfiler는 "JProfiler 설치" 도움말 항목에서 설명한 에이전트 패키지를 업로드하고 원격 머신에서 포함된 커맨드 라인 도구를 실행할 수 있습니다. 로컬 머신에 SSH가 설정되어 있을 필요가 없으며, JProfiler는 자체 구현을 포함하고 있습니다. 가장 간단한 설정에서는 호스트, 사용자 이름 및 인증 정보만 정의하면 됩니다.
SSH 연결을 통해 JProfiler는 실행 중인 JVM을 자동으로 검색하거나 프로파일링 에이전트가 이미 수신 대기 중인
특정 포트에 연결할 수 있습니다. 후자의 경우, 위에서 설명한 대로 원격 머신에서
jpenable 또는 jpintegrate를 사용하여
프로파일링을 위한 특정 JVM을 준비할 수 있습니다. 그런 다음 SSH 원격 attach가 설정된 프로파일링 포트에
직접 연결하도록 구성할 수 있습니다.
자동 검색은 SSH 로그인 사용자로 시작된 원격 머신의 모든 JVM을 나열합니다. 대부분의 경우
이는 프로파일링하려는 서비스를 시작한 사용자가 아닐 것입니다. 서비스를 시작하는 사용자는 일반적으로
SSH 연결이 허용되지 않으므로, JProfiler는 Switch User 하이퍼링크를 추가하여
sudo 또는 su를 사용해 해당 사용자로 전환할 수 있게 합니다.
복잡한 네트워크 토폴로지에서는 원격 머신에 직접 연결할 수 없는 경우가 있습니다. 이 경우 GUI에서 멀티 홉 SSH 터널로 연결하도록 JProfiler에 지시할 수 있습니다. SSH 터널의 끝에서 일반적으로 "127.0.0.1"로 하나의 직접 네트워크 연결을 만들 수 있습니다.
다른 인증 메커니즘의 경우 OpenSSH 터널 모드를 사용할 수 있습니다. OpenSSH 실행 파일을 사용할 때 커맨드 라인에 입력하는 것처럼 호스트 이름을 입력합니다. 이는 OpenSSH 설정 파일에 구성된 별칭일 수도 있습니다. 호스트 이름 외에 포트와 사용자 이름을 선택적으로 지정할 수 있습니다. Windows에서는 Microsoft의 내장 OpenSSH 클라이언트만 지원됩니다.
SSH 옵션 텍스트 필드는 커맨드 라인에서 지정할 OpenSSH 실행 파일에 대한 임의의 추가 인수를 받습니다. 이는 예를 들어 AWS 세션 매니저를 통해 SSH 연결을 터널링하는 방법과 같은 튜토리얼의 지침을 따를 때 특히 유용합니다.
HPROF 스냅샷은 SSH 로그인 사용자로 시작된 JVM에 대해서만 생성할 수 있습니다. HPROF 스냅샷은 JVM을 시작한 사용자의 접근 권한으로 작성되는 중간 파일이 필요하기 때문입니다. 보안상의 이유로 다운로드를 위해 SSH 로그인 사용자에게 파일 권한을 이전하는 것은 불가능합니다. 전체 프로파일링 세션에는 이러한 제한이 없습니다.
Docker 컨테이너에서 실행 중인 JVM에 Attach하기
Docker 컨테이너에는 일반적으로 SSH 서버가 설치되어 있지 않으며, Docker 컨테이너에서 jpenable을 사용할 수 있지만 Dockerfile에 지정하지 않는 한 프로파일링 포트는 외부에서 접근할 수 없습니다.
JProfiler에서는 quick attach 대화상자에서 Docker 컨테이너를 선택하여 Windows 또는 macOS의
로컬 Docker Desktop 설치에서 실행 중인 JVM에 attach할 수 있습니다. 기본적으로 JProfiler는
docker 실행 파일의 경로를 자동으로 감지합니다. 또는 일반 설정 대화상자의
"External tools" 탭에서 구성할 수 있습니다.
컨테이너를 선택하면 Docker 컨테이너 내에서 실행 중인 모든 JVM이 표시됩니다. JVM을 선택하면 JProfiler는 Docker 명령을 사용하여 선택한 컨테이너에 프로파일링 에이전트를 자동으로 설치하고, JVM을 프로파일링 준비 상태로 만들고, 프로파일링 프로토콜을 외부로 터널링합니다.
원격 Docker 설치의 경우 SSH 원격 attach 기능을 사용하여 원격 머신의 Docker 컨테이너를 선택할 수 있습니다. 로그인 사용자가 docker 그룹에 속하지 않는 경우, 위에서 설명한 대로 먼저 사용자를 전환할 수 있습니다.
원격 attach 대화상자의 Select container 하이퍼링크를 사용하여 실행 중인 Docker 컨테이너를 선택하고 그 안에서 실행 중인 모든 JVM을 표시할 수 있습니다.
Kubernetes 클러스터에서 실행 중인 JVM에 Attach하기
Kubernetes 클러스터에서 실행 중인 JVM을 프로파일링하기 위해 JProfiler는 kubectl
커맨드 라인 도구를 사용합니다. 파드와 컨테이너를 검색하고, 컨테이너에 연결하고, JVM을 나열하고,
최종적으로 선택한 JVM에 연결하는 데 모두 이 도구를 사용합니다.
kubectl 커맨드 라인 도구는 로컬 컴퓨터에서 사용하거나 SSH 접근이 가능한
원격 머신에서 사용할 수 있습니다. JProfiler는 두 가지 시나리오를 모두 직접 지원합니다.
로컬 설치의 경우 JProfiler는 kubectl의 경로를 자동으로 감지하려 하지만,
일반 설정 대화상자의 "External tools" 탭에서 명시적인 경로를 구성할 수 있습니다.
JProfiler는 감지된 모든 컨테이너를 세 단계의 트리로 나열합니다. 최상위에는 감지된 파드를 포함하는 자식 노드가 있는 네임스페이스 노드가 있습니다. 리프 노드는 컨테이너 자체이며, 실행 중인 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도 인식합니다.
