프로파일링 세션을 설정할 수 없는 경우, 가장 먼저 해야 할 일은 프로파일된 애플리케이션 또는 애플리케이션 서버의 터미널 출력을 확인하는 것입니다. 애플리케이션 서버의 경우, stderr 스트림이 종종
로그 파일로 기록됩니다. 이 로그 파일은 애플리케이션 서버의 메인 로그 파일과 별도의 파일일 수 있습니다. 예를 들어, WebSphere 애플리케이션 서버는
native_stderr.log 파일에 stderr 출력만을 포함하여 기록합니다. stderr 출력의 내용에 따라 문제를 찾는 방향이 달라집니다:
커넥션 문제
stderr에 "Waiting for connection ..."이 포함되어 있다면, 프로파일된 애플리케이션의 설정은 정상입니다. 이 경우 문제는 다음과 같은 질문들과
관련이 있을 수 있습니다:
- 로컬 머신의 JProfiler GUI에서 "Attach to remote JVM" 세션을 시작하는 것을 잊지 않으셨나요? 프로파일링 에이전트가 "nowait" 옵션으로 즉시 시작하도록 설정되어 있지 않다면, JProfiler GUI가 연결될 때까지 VM이 시작을 대기하게 됩니다.
- 세션 설정에서 호스트 이름 또는 IP 주소가 올바르게 설정되어 있나요?
-
잘못된 통신 포트를 설정하지는 않았나요? 통신 포트는 HTTP나 다른 표준 포트 번호와는 무관하며, 이미 사용 중인 포트와 동일해서는 안 됩니다. 프로파일된 애플리케이션의 경우, 통신 포트는
프로파일링 VM 파라미터의 옵션으로 정의됩니다. VM 파라미터
-agentpath:<path to jprofilerti library>=port=25000을 사용하면 25000 포트가 사용됩니다. -
루프백 인터페이스에서만 listen하는 에이전트에 직접 커넥션을 시도하고 있나요? 기본적으로 에이전트는 루프백 인터페이스에서만 listen합니다. JProfiler에서 SSH 터널을 설정하여 원격
머신에 연결하도록 구성할 수 있습니다. 암호화가 필요하지 않다면,
address=[IP address]옵션을-agentpath파라미터에 사용할 수도 있습니다. - 로컬 머신과 원격 머신 사이에 방화벽이 있나요? 인바운드뿐만 아니라 아웃바운드 커넥션에 대한 방화벽이나, 중간 게이트웨이 머신에 방화벽이 있을 수 있습니다.
포트 바인딩 문제
stderr에 socket을 바인딩할 수 없다는 에러 메시지가 있다면, 해당 포트가 이미 사용 중입니다. 이 경우 다음 사항을 확인하세요:
- 프로파일된 애플리케이션을 여러 번 시작하지는 않았나요? 각 프로파일된 애플리케이션은 별도의 통신 포트가 필요합니다.
- 이전 프로파일링 실행에서 남은 좀비 Java 프로세스가 포트를 점유하고 있지는 않나요?
- 다른 애플리케이션이 해당 통신 포트를 사용하고 있지는 않나요?
stderr에 JProfiler>로 시작하는 라인이 없고, 애플리케이션 또는 애플리케이션 서버가 정상적으로 시작된다면, -agentpath:[path to jprofilerti library]
VM 파라미터가 Java 호출에 포함되지 않은 것입니다. 실제로 실행되는 Java 호출이 어떤 것인지 시작 스크립트에서 확인한 후, 해당 위치에 VM 파라미터를 추가해야 합니다.
attach 문제
실행 중인 JVM에 attach할 때, 관심 있는 JVM이 모든 JVM 목록에 보이지 않을 수 있습니다. 이 문제의 원인을 찾으려면 attach 메커니즘이 어떻게 동작하는지 이해하는 것이 중요합니다.
JVM이 시작되면, 임시 디렉터리 내 hsperfdata_$USER 디렉터리에 PID 파일을 기록하여 이를 통해 JVM을 탐지합니다. 동일한 사용자 또는 admin 사용자만 해당
JVM에 attach할 수 있습니다. JProfiler는 admin 사용자로 JVM에 연결하는 데 도움을 줄 수 있습니다.
Windows에서는 Show Services 버튼을 사용하여 모든 JVM 서비스 프로세스를 표시할 수 있습니다. JProfiler는 시스템 계정으로 실행되는 서비스와, 설정된 사용자 계정으로 실행되는 서비스 모두에 연결할 수 있도록 도와주는 helper service를 설치합니다. 해당 서비스의 이름은 "JProfiler helper"이며, 해당 버튼을 클릭하면 설치됩니다. 서비스 설치를 허용하려면 UAC 프롬프트를 승인해야 합니다. JProfiler를 종료하면 서비스는 다시 제거됩니다.
Linux에서는 attach 다이얼로그의 사용자 전환 기능을 사용하여 root 계정으로 attach할 수 있습니다. 이 사용자 전환 기능은 로컬 JVM 프로파일링 시뿐만 아니라, 원격 Linux 또는 macOS 머신에 attach할 때도 표시됩니다. 원격 attach의 경우, root가 아닌 다른 사용자로도 전환할 수 있습니다. root 비밀번호가 있다면, 실제 서비스를 실행하는 사용자 대신 항상 root로 전환하는 것이 좋습니다.
Linux에서 JVM이 보여야 함에도 보이지 않는 경우, 문제는 보통 임시 디렉터리와 관련이 있습니다. 한 가지 가능성은 /tmp/hsperfdata_$USER 디렉터리의 접근
권한이 잘못된 경우입니다. 이 경우, 해당 디렉터리를 삭제하고 JVM을 재시작하세요. attach 대상 프로세스는 /tmp에 쓰기 권한이 있어야 하며, 그렇지 않으면 attach가 지원되지 않습니다.
systemd를 사용하는 경우, 관심 있는 프로세스의 systemd 서비스 파일에 PrivateTmp=yes가 설정되어 있을 수 있습니다. 이 경우 pid
파일이 다른 위치에 기록됩니다. attach 다이얼로그의 사용자 전환 기능으로 root 사용자로 전환하거나, CLI 도구를 root로 실행하면 JProfiler가 이를 처리합니다.
원격 attach를 위한 에이전트 자동 다운로드
원격 attach의 경우, JProfiler는 원격 대상 플랫폼에 맞는 agent 라이브러리가 필요합니다. 로컬에 없을 경우, 자동으로 다운로드를 시도합니다. 이 작업은
https://download.ej-technologies.com에 대한 HTTPS 커넥션을 방화벽이 차단하거나, SSL 커넥션을 중간자
공격(man-in-the-middle) 방식으로 검사하여 트래픽을 복호화하는 경우 실패할 수 있습니다. 후자의 경우, JProfiler가 방화벽의 인증서를 가지고 있지 않으므로 HTTPS 커넥션이
실패합니다.
에이전트 다운로드 오류가 발생하면, JProfiler는 수동 우회 방법을 제공합니다. 다이얼로그가 표시되어 웹사이트에서 에이전트 아카이브를 수동으로 다운로드하고, 다운로드한 아카이브의 위치를 지정한 후 원격 attach 작업을 계속하는 방법을 안내합니다.
에이전트 파일은 캐시되므로, 각 원격 플랫폼마다 한 번만 이 작업을 수행하면 됩니다. JProfiler가 업데이트되면 에이전트가 변경되므로, 다운로드를 다시 해야 합니다.
