고성능 Java 애플리케이션을 구축하기 위해 알아야 할 5가지

이 글은 "자바 성능"에서 발췌한 내용입니다. 자바 성능에 좀 더 관심이 있는 학생들이라면 아마 이 책을 알고 계실 겁니다. 많은 학생들이 일상적으로 자바 코드를 작성할 때 별로 신경쓰지 않는 부분이겠지만, 우리의 경우에는 코드 작성 과정에서 비트 연산을 사용하여 산술 연산을 구현하는 것부터 JAVA 코드의 전체 아키텍처 설계에 이르기까지 프로그램 성능에 미치는 영향은 실제로 우리에게 매우 가깝습니다. 이 기사에서는 주로 공연 분야에서 우리가 더 우려하는 몇 가지 문제를 언급하며, 학생들이 공연에 관심이 있다면 각 사항을 함께 깊이 공부할 수 있습니다.

성능 튜닝에는 일반적으로 3단계가 있습니다: 1. 성능 모니터링 2. 성능 분석 3. 성능 튜닝

운영 체제 성능에 대한 우리의 주요 관심사는 다음과 같습니다. 포인트: CPU 활용도, CPU 스케줄링 실행 큐, 메모리 활용도, 네트워크 I/O, 디스크 I/O.

1.CPU 활용

어플리케이션의 경우, 애플리케이션이 최고의 성능과 확장성을 달성하기 위해서는 CPU 주기의 사용 가능한 부분을 최대한 활용해야 할 뿐만 아니라 또한 CPU의 이 부분을 낭비하는 것보다 더 가치 있게 활용하십시오. 다중 프로세서 및 다중 코어 시스템에서 실행되는 다중 스레드 응용 프로그램의 경우 CPU 주기를 최대한 활용하는 것은 매우 어렵습니다. 또한, CPU가 포화 상태에 도달했다고 해서 CPU의 성능과 확장성이 최적의 상태에 도달했다는 의미는 아닙니다. 애플리케이션이 CPU 리소스를 활용하는 방식을 구별하려면 운영 체제 수준에서 이를 감지해야 합니다. 많은 운영 체제에서 CPU 사용률 통계 보고서에는 일반적으로 운영 체제의 사용자 및 시스템 또는 커널 사용량이 포함됩니다. 사용자의 CPU 사용량은 애플리케이션이 애플리케이션 코드 실행을 수행하는 데 사용하는 시간입니다. 이와 대조적으로, 커널 및 시스템 CPU 사용량은 애플리케이션이 운영 체제 커널 코드 잠금을 실행하는 데 소비하는 시간을 나타냅니다. 커널 또는 시스템 CPU 사용량이 높다는 것은 공유 리소스가 부족하거나 I/O 장치 상호 작용이 많다는 것을 의미할 수 있습니다. 애플리케이션 성능과 확장성을 향상시키기 위해서는 커널이나 시스템 CPU 시간을 0%로 허용하는 것이 이상적인 상태입니다. 커널이나 시스템 코드를 실행하는 데 소요된 시간이 애플리케이션 코드를 실행하는 데 사용될 수 있기 때문입니다. 따라서 CPU 사용량 최적화의 올바른 방향은 CPU가 커널 코드나 시스템 코드를 실행하는 데 소요되는 시간을 최대한 줄이는 것입니다.

컴퓨팅 집약적인 애플리케이션의 경우 성능 모니터링은 사용자 CPU 사용량과 커널 또는 시스템 CPU 사용량을 모니터링하는 것보다 더 심층적입니다. 컴퓨팅 집약적인 애플리케이션에서는 CPU 클록 주기 내에서 실행 횟수를 모니터링해야 합니다. 클록, IPC) 또는 각 CPU 실행에 사용되는 CPU 사이클(명령당 사이클, CPI)입니다. 컴퓨팅 집약적인 응용 프로그램의 경우 이러한 두 가지 차원에서 CPU를 모니터링하는 것이 좋은 선택입니다. 최신 운영 체제의 패키지 CPU 성능 보고 도구는 일반적으로 CPU 사용률만 인쇄하고 CPU 주기 동안의 CPU 사용량은 인쇄하지 않기 때문입니다. 명령을 실행합니다. 이는 CPU가 메모리에서 데이터를 기다리고 있을 때 운영 체제 CPU 성능 보고 도구도 CPU가 사용 중인 것으로 간주함을 의미합니다. 이러한 시나리오는 다음과 같은 경우에 자주 발생합니다. CPU 명령에 필요한 데이터가 준비되지 않은 한, 즉 레지스터나 CPU 캐시에 없는 한 명령이 실행될 때마다 "지속" 시나리오가 발생합니다.

"스톨" 시나리오가 발생하면 CPU는 명령에 필요한 데이터가 레지스터나 버퍼에 도착할 때까지 기다려야 하기 때문에 CPU는 클럭 사이클을 낭비하게 됩니다. 그리고 이 시나리오에서는 수백 개의 CPU 클럭 사이클이 낭비되는 것이 정상입니다. 따라서 컴퓨팅 집약적인 애플리케이션에서 성능을 향상하기 위한 전략은 "스톨" 시나리오의 발생을 줄이거나 CPU 캐시의 사용을 향상시키는 것입니다. 데이터를 기다리는 데 낭비되는 CPU 주기가 줄어듭니다. 이러한 유형의 성능 모니터링 지식은 이 책의 내용을 벗어나므로 성능 전문가의 도움이 필요합니다. 그러나 나중에 언급되는 성능 분석 도구인 Oracle Solaris Studio Performance Analyser에는 이러한 데이터가 포함됩니다.

2.CPU 스케줄링 큐

CPU 사용량 모니터링 외에도 CPU 실행 큐를 모니터링하여 시스템이 완전히 로드되었는지 확인할 수도 있습니다. 실행 큐는 경량 프로세스를 저장하는 데 사용됩니다. 이러한 프로세스는 일반적으로 실행 준비가 되어 있지만 CPU 스케줄링을 기다리고 있으며 현재 프로세서가 처리할 수 있는 경량 프로세스 수가 증가할 때, 많은 경우 예약 대기열이 생성됩니다. 깊은 CPU 디스패치 큐는 시스템이 완전히 로드되었음을 나타냅니다. 시스템의 실행 큐 깊이는 가상 프로세서가 실행할 수 없는 대기 수와 같고, 가상 프로세서 수는 시스템의 하드웨어 스레드 수와 같습니다. Java의 API를 사용하여 가상 프로세서 수인 Runtime.avaliableProcessors()를 얻을 수 있습니다. 실행 큐 깊이가 가상 프로세서 수의 4배 이상이면 운영 체제가 응답하지 않게 됩니다.

CPU 스케줄링 대기열을 감지하기 위한 일반적인 지침은 대기열 깊이가 가상 프로세스 수의 두 배보다 높지만 즉각적인 조치를 취할 필요가 없는 경우 주의를 기울이는 것입니다. 3배 이상, 4배 이상일 때에는 주의를 기울여 지체 없이 문제를 해결해야 합니다.

대개 대기열의 깊이를 관찰하는 두 가지 선택적 방법이 있습니다. 첫 번째는 CPU를 추가하거나 기존 CPU의 부하를 줄여 부하를 공유하는 것입니다. 이 접근 방식은 기본적으로 실행 단위당 로드 스레드 수를 줄여 실행 대기열의 깊이를 줄입니다.

또 다른 방법은 시스템에서 실행되는 애플리케이션을 프로파일링하여 CPU 사용량을 늘리는 것입니다. 즉, 가비지 수집에 소요되는 CPU 주기를 줄이는 방법을 찾거나 CPU 주기를 줄이는 더 나은 알고리즘을 찾는 것입니다. CPU 명령을 실행합니다. 성능 전문가는 일반적으로 후자의 접근 방식, 즉 코드 실행 경로 길이를 줄이고 더 나은 CPU 명령 선택에 중점을 둡니다. JAVA 프로그래머는 더 나은 실행 알고리즘과 데이터 구조를 통해 코드 실행 효율성을 향상시킬 수 있습니다.

3. 메모리 활용도

CPU 사용량 외에도 시스템의 메모리 속성도 모니터링해야 합니다. 이러한 속성에는 페이징, 스와핑, 잠금, 컨텍스트 전환 발생 등이 포함됩니다. 멀티스레딩 등을 통해 .

스왑은 일반적으로 애플리케이션에 필요한 메모리가 실제 물리적 메모리보다 클 때 발생합니다. 이러한 상황을 처리하기 위해 운영 체제에서는 일반적으로 스왑 영역이라는 해당 영역을 구성합니다. 스왑 영역은 일반적으로 물리 디스크에 위치합니다. 물리 메모리의 응용 프로그램이 고갈되면 운영 체제는 메모리 데이터의 일부를 디스크 공간으로 일시적으로 스왑합니다. 메모리 영역의 이 부분은 일반적으로 가장 낮은 영역입니다. 비교에 영향을 주지 않고 액세스 빈도 "사용 중" 메모리 영역, 디스크 영역으로 스왑된 메모리가 애플리케이션에 의해 액세스될 때 페이지 단위로 디스크 스왑 영역에서 메모리를 읽어야 합니다. 응용 프로그램의.

가비지 수집기가 방문하는 대부분의 영역에 도달할 수 없기 때문에 가상 머신의 가비지 수집기 성능은 스와핑 중에 매우 저하됩니다. 즉, 가비지 수집기로 인해 스와핑 활동이 발생하게 됩니다. 가비지 수집된 힙 영역이 디스크 공간으로 스왑된 경우 이때 페이지 단위로 스와핑이 이루어지기 때문에 가비지 컬렉터가 이를 스캔하는 과정에서 가비지가 극적으로 발생하게 됩니다. 수집기의 수집 시간이 연장됩니다. 이때 가비지 수집기가 "Stop The World"(애플리케이션 응답을 중지함)인 경우 이 시간이 연장됩니다.

4. 네트워크 I/O

분산 JAVA 애플리케이션의 성능과 확장성은 네트워크 대역폭과 네트워크 성능에 의해 제한됩니다. 예를 들어, 처리할 수 있는 것보다 더 많은 패킷을 네트워크 인터페이스에 보내면 운영 체제의 버퍼에 패킷이 축적되어 애플리케이션 지연이 발생하고 다른 상황에서도 네트워크 애플리케이션 지연이 발생합니다.

차별화 및 모니터링 도구는 운영 체제 패키징 도구에서 찾기 어려운 경우가 많습니다. Linux는 netstat 명령을 제공하지만 Linux와 Solaris는 모두 패킷 전송, 패킷 수신, 오류 패킷, 충돌 및 기타 초당 정보를 포함한 통계를 제공합니다. 이더넷에서는 적은 수의 패킷 충돌이 발생하는 것이 정상입니다. 패킷 오류가 많은 경우 네트워크 카드에 문제가 있을 수 있습니다. 동시에 netstat는 네트워크 인터페이스의 송수신 데이터를 계산할 수 있지만 네트워크 카드가 완전히 활용되는지 여부를 판단하기는 어렵습니다. 예를 들어, netstat -i에 초당 2500개의 패킷이 네트워크 카드에서 전송된다고 표시되지만 현재 네트워크 사용률이 100%인지 1%인지 여전히 확인할 수 없는 경우 현재 트래픽이 있다는 것만 알 수 있습니다. 이는 네트워크 패킷 크기를 모르더라도 도달할 수 있는 결론일 뿐입니다. 간단히 말해, Linux와 Solaris에서 제공하는 netstat를 사용하여 현재 네트워크가 성능에 영향을 미치는지 확인할 수 없습니다. JAVA 애플리케이션이 실행되는 동안 네트워크를 모니터링하려면 다른 도구가 필요합니다.

5. 디스크 I/O

애플리케이션이 디스크에서 작동하는 경우 디스크 성능 문제를 모니터링하기 위해 디스크를 모니터링해야 합니다. 데이터베이스와 같은 일부 애플리케이션은 I/O 집약적입니다. 디스크 사용은 일반적으로 응용 프로그램 로그 시스템에도 존재합니다. 로그는 일반적으로 시스템 작동 중에 중요한 정보를 기록하는 데 사용됩니다.