 |
|
난이도 : 중급 Sean Walberg, Senior Network Engineer, Freelance
원문 게재일 : 2009 년 4 월 28 일
번역 게재일 : 2009 년 7 월 28 일 최상의 애플리케이션이라고 하더라도 기본 호스트가 올바르게 구성되어 있지 않으면
성능을 제대로 발휘할 수가 없습니다. 이 기사에서는 성능 조정과 관련된 4가지 주요 영역을 살펴보고
각 영역에서 감시할 항목을 식별합니다. 또한 Java 기반 애플리케이션의 경우에는 성능 조정을 위한
추가 요구 사항이 있으며 특히 가비지 콜렉션 주기와 관련된 요구 사항이 중요합니다. 이 기사에서는
가비지 콜렉션에 관한 중요한 내용도 설명합니다.
서버에는 워크로드를 효과적으로 처리하기 위해 변경할 수 있는 여러 가지 설정이 있다. 파일
서버는 데이터베이스 서버와 다른 방식으로 조정되며 두 애플리케이션 서버 또한 해당 서버의 로드
특성에 따라 다른 방식으로 조정될 수 있다. 조정 작업은 애플리케이션이 최대한 잘 작동할 수
있도록 서버의 유한한 리소스를 운영 체제 및 애플리케이션의 다양한 부분에 할당하는 작업이다. 고려할 영역은 다음과 같다.
- CPU(Central Processing Unit)
- 메모리
- 디스크(공간 및 액세스 속도)
- 네트워크
이러한 영역은 서로 밀접하게 연관되어 있다. 예를 들어, 메모리를 캐시 작업에 할당하여
디스크 액세스 횟수를 줄이거나 로컬 디스크에서 직접 읽지 않고 네트워크를 통해 리소스에
액세스할 수 있다. 이 기사에서는 특별히 JVM(Java Virtual Machine)과 관련된 메모리 조정에
대해 살펴본다. JVM에는 사용자가 모니터링 및 구성해야 하는 고유한 메모리 관리 시스템이 있다.
CPU
서버의 CPU는 수행할 작업을 대기하는 데 많은 시간을 소비하게 된다. 특히, 디스크에서 리턴되는
데이터를 대기하는 데 소비되는 시간이 가장 많다. 멀티태스킹이 지원되면 CPU가 대기하는 중에도 다른
작업을 수행할 수 있다. 따라서 호스트가 이러한 CPU 상태에서 많은 시간을 보내는 경우에는 빠른 CPU를
구입하는 것이 효율적이다.
vmstat 명령은 시스템의 현재 상태에 대한 실시간 정보를 제공하며
sar 도구 세트는 장기간 모니터링에 유용하다. 이들 도구를 실행하여
CPU가 사용자 공간에서 대부분의 시간을 보내고 있고 유휴 주기가 줄어들고 있다는 결과가 나오면
다음에 수행할 작업을 결정해야 한다. 이 상황에서는 로드를 다른 서버로 분배하거나 CPU 용량을
늘려야 한다.
로드를 분배한다는 것은 다른 서버에서 일괄 처리 작업을 실행하거나 애플리케이션 로드를 여러
서버로 분할한다는 것을 의미한다. 이 마지막 방법이 이상적이며 이를 수평 조정이라고도 한다. CPU
용량을 증가시켜야 하는 경우 CPU를 추가하는 등의 방법으로 물리적 업그레이드를 수행할 수 있으며
가상 환경에 있는 경우에는 추가 리소스를 다시 할당할 수도 있다.
일부 로드는 병렬 처리에 적합하지 않으며 이 경우 여러 서버에 로드를 분할하거나 CPU를 추가하는
것은 도움이 되지 않으며 CPU의 속도를 높여서 문제를 해결하고 주기의 수를 줄여서 기본 코드를 최적화하는
것이 효과적이다.
메모리
메모리 조정에는 여러 항목이 관련되어 있다. 가장 간단한 방법은 스왑 공간을 사용하지 않고도
애플리케이션을 지원할 수 있을 정도로 충분한 용량의 RAM을 사용하는 것이다. 운영 체제의 가상 메모리
서브시스템은 디스크에 임시 저장소를 만들어서 애플리케이션에서 시스템의 실제 메모리보다 많은 메모리를
할당할 수 있도록 지원한다. 메모리 블록을 디스크에서 페이징하게 되면 RAM에서 직접 액세스할 때보다
속도가 많이 느려지므로 일반적으로 이 방법은 사용하지 않는 것이 좋다.
즉, 가상 메모리 서브시스템을 사용하려면 시스템의 메모리가 부족해지기 전에 블록이 디스크에 기록될 수
있고 예기치 않은 문제로 인해 스왑 공간을 사용해야 하는 경우도 발생할 수 있기 때문에 약간의 조정 작업이
필요하다. 기본적으로 수행할 작업은 가상 메모리가 사용되는 시기를 확인하는 것이다. UNIX® 시스템에서는
여유 메모리가 할당되어감에 따라 결국에는 커널이 스왑 아웃할 후보 메모리 페이지를 찾기 시작해야 한다는
것을 결정하게 된다. 이 결정이 내려진 직후 커널은 메모리를 할당하고 있는 프로세스에 메모리를 할당해야 하는
상황을 예상하고 일부 페이지를 디스크에 스왑핑하기 시작한다. 워크로드를 처리하기에 충분한 메모리가 있는
경우에는 이러한 두 가지 스왑 활동을 지연시키는 것이 좋다.
Solaris™에서는 /etc/system에 있는 tunables를 통해 이 작업을 수행하며 IBM® AIX®
운영 체제에서는 vmo 명령을 사용하고 Linux®에서는 /etc/sysctl.conf를
사용한다. 이러한 동작은 운영 체제의 발전에 따라 지속적으로 변하고 있으므로 변경 작업을 수행하기 전에
관련 주제를 자세히 살펴야 한다.
마지막으로 추가 메모리를 사용하면 파일 시스템에서 파일과 메타데이터를 메모리에 캐시할
수 있다. 대부분의 UNIX 시스템에서는 여유 메모리를 캐시로 사용하려고 하기 때문에 시스템에
여유 메모리가 없는 것처럼 보일 때가 많다. 이렇게 하면 디스크 활동이 줄어들기 때문에 웹 서버와
같은 일부 워크로드에서 큰 효과를 볼 수 있다.
디스크
디스크는 메모리에 비해 느리므로 디스크 활동이 과도하면 많은 애플리케이션의 성능이
저하된다. 디스크 활동은 앞에서 설명한 스왑핑에 의해 발생할 수 있으며 애플리케이션 또는
운영 체제의 요청에 의해서도 발생할 수 있다. 로깅 작업이 과도할 경우에도 디스크에서
경합이 발생할 수 있다.
디스크 병목 현상을 찾아내는 데 가장 좋은 도구는 iostat이다. 이
도구는 특정 시점에 발생하고 있는 읽기 및 쓰기 횟수와 디스크 컨트롤러의 포화도를 알려 준다. 여러
개의 디스크가 있는 경우 로드를 개별 스핀들로 분할하면 디스크 지연 시간의 가장 큰 원인이 되는
검색 시간이 줄어들기 때문에 읽기 및 쓰기 시간을 효과적으로 단축시킬 수 있다. 로그 파일 및 데이터베이스
저널과 같이 지속적으로 커지는 파일은 애플리케이션의 디스크 및 데이터베이스와 다른 디스크에 있어야
한다.
vmstat 및 iostat는 둘 다 시스템이 iowait 상태에서
보낸 시간 즉, CPU가 유휴 상태에 있는 동안 시스템이 IO의 리턴을 기다리고 있는 시간에 대한 백분율 정보를
제공한다. iowait 값이 높다는 것은 디스크의 속도가 느리거나 오버로드가 발생했다는 것을 나타낸다.
열릴 수 있는 파일 디스크립터의 수는 디스크와 밀접히 관련되어 있다. 파일 디스크립터가 모두
사용 중일 경우에는 파일을 새로 열 수가 없다. 일반적으로 ulimit 명령을
사용하여 사용 가능한 파일 디스크립터의 수를 늘릴 수 있다. 하지만 ulimit를
사용할 수 없도록 운영 체제에 커널 제한이 설정되어 있을 수도 있다.
네트워크
네트워크는 서버와 클라이언트 간에 데이터를 교환하는 데 사용되므로 대부분의
애플리케이션에서 중요한 위치를 차지하고 있다. 네트워크가 느리다는 것은 애플리케이션의
응답 속도가 느리다는 것을 의미한다. 가장 먼저 수행할 조치는 모든 서버가 전이중
방식의 최대 속도로 고정되어 있고 스위치 포트가 적절하게 설정되어 있는지 여부를
확인하는 것이다. 스위치와 서버 간에 일치하지 않는 속도 및 전송 방식으로 인해 네트워크
문제가 자주 발생하고 있다.
운영 체제에서는 다양한 버퍼를 네트워크 리소스에 할당한다. 예를 들어, 운영 체제에서는
각 TCP 연결에 대한 TCP 전송 큐를 관리한다. 이 큐에는 애플리케이션에서는 보냈지만 원격
대상에서 아직 승인되지 않은(그리고 승인되지 않은 패킷의 수에 따라 네트워크에서 전송되지 않을
수도 있는) 데이터가 저장된다. 이 큐가 꽉 차게 되면 백로그가 정리될 때까지 애플리케이션에서는
더 이상 데이터를 보낼 수 없다.
네트워크 카운터 목록을 보여 주는 netstat -s를 사용하면 버퍼
정체를 파악할 수 있다. 이 목록에서 "queue" 또는 "overflow"라는 단어가 포함된 모든 항목은
TCP 큐와 관련되므로 모니터링해야 한다. 이들 카운터는 일반적으로 부팅 시에만 재설정되므로
시간이 지날수록 숫자가 커지므로 더 많은 주의를 기울여야 한다.
netstat -an을 실행하여 대기 상태(예: CLOSE_WAIT
또는 FIN_WAIT_1)에 있는 연결 수가 높게 나타나는 경우에는 시스템의 모든 리소스가
이러한 오래된 연결을 가지고 있기 때문에 새 연결을 설정하는 데 문제가 발생할 수 있다. 이 경우에는
ndd(Solaris의 경우) 또는 no(AIX의 경우)를
사용하여 운영 체제에서 연결이 유지되는 시간을 제어하는 제한 시간을 줄일 수 있다.
Java 메모리 자세히 보기
이전 섹션까지는 시스템에서 조정이 필요한 네 가지 영역에 대해 살펴보았으며 그 중
하나가 메모리였다. Java 애플리케이션 환경에서는 서버가 애플리케이션 코드를 실행하는
Java 프로세스에 메모리를 할당한다. JVM이라고도 하는 이 Java 프로세스는 기본 애플리케이션에
메모리를 할당하는 역할도 수행한다.
운영 체제 계층에서 1GB의 메모리가 Java 프로세스에 할당된 것을 볼 수 있다. 이 프로세스
내에서 JVM은 새 오브젝트에 대한 메모리로 사용되는 힙을 관리한다. 오브젝트는 작성된 후 힙에
배치되며 삭제된 후에도 힙에 남아 있다. JVM에 의해 실행되는 가비지 콜렉션이라는
프로세스는 알려져 있는 작성된 모든 오브젝트를 표시한 후 후속 할당 작업을 위해 힙의 나머지
부분을 정리한다. 이 시점에서 힙은 확장(가비지 콜렉션이 새 할당에 사용할 메모리가 부족한
경우) 또는 축소(JVM이 힙이 과도하게 크다고 판단하게 되는 특정 조건에 도달한 경우)될 수 있다.
가비지 콜렉션에 대한 이 간단한 정의를 좀 더 따져보면 가비지 콜렉션이 발생하는 동안에는
시스템에서 어떠한 애플리케이션 작업도 수행되지 않는다는 것을 알 수 있다. 가비지 콜렉션이
실행되는 동안 JVM은 효과적으로 일시 중지된다. 따라서 Java 조정 작업의 많은 부분은 최적의
메모리 크기를 결정하고 가비지 콜렉션 프로세스를 미세 조정하는 것과 관련된다.
가비지 콜렉션 프로세스를 조정하는 작업은 크게 보면 가비지 콜렉션의 실행 빈도 및 실행 조건을
파악한 후 JVM 설정을 변경하여 실행되는 가비지 콜렉션의 영향을 최소화하는 것이다.
가비지 콜렉션 정보 수집하기
가비지 콜렉션이 애플리케이션에 미치는 영향을 파악하기 위해 가장 먼저 수행할 단계는
가비지 콜렉션이 수행되는 시기와 빈도에 대한 정보를 수집하는 것이다. JVM에서 자세한 가비지
콜렉션 로깅을 활성화한다. 그러면 가비지 콜렉션 활동에 대한 로깅이 시작된다. IBM WebSphere™
Application Server의 경우 Integrated Solutions Console 내에서 Application servers > server name
> Process Definition > Java Virtual Machine으로 이동한 후 Verbose Garbage Collection을
선택하면 관리 콘솔에서 이 설정을 확인할 수 있다.
또는 -verbose:gc 매개변수를 사용하여 JVM을 시작한다(Integrated
Solutions Console 옵션이 수행하는 작업). 두 경우 모두 JVM의 출력에 가비지 콜렉션 정보가 포함된다.
자세한 가비지 콜렉션 로깅을 사용할 때 아쉬운 부분은 공급업체 간에 파일의 형식이 일관되지 않는다는
것이다. 심지어 같은 공급업체라고 하더라도 버전이 다를 경우 파일의 형식이 일관되지 않을 수 있다. 예를
들어, IBM의 JRE(Java Runtime Environment) 6.0에서는 자세한 XML(Extensible Markup Language) 파일 형식으로
로그가 작성되지만 Sun Microsystems의 HotSpot JVM에서는 필요한 정보를 얻기 위해 추가 명령행 매개변수가
필요할 수도 있는 한 줄로 된 간단한 형식을 사용한다.
가비지 콜렉션 데이터 이해하기
이제 가비지 콜렉터의 정보가 기록되고 있으므로 일반적으로 로드 하에서 애플리케이션을
실행한 후 가비지 콜렉션 로그를 검사한다. 그러면 힙의 크기가 처음 할당된 용량부터 시작하여
점차 늘어나다가 일정 범위의 값에 도달하게 된다. 이제 이 범위 내의 한 값을 힙의 초기 값으로
사용할 수 있다. 이렇게 하면 힙의 크기가 늘어나면서 안정적인 상태의 값에 도달하는 데 걸리는
초기 지연 시간을 방지할 수 있다.
가비지 콜렉션 로그에는 가비지 콜렉션의 시작 시간과 실행 기간도 표시된다. 가비지 콜렉션의 실행
기간이 너무 긴 경우에는 다른 가비지 콜렉션 알고리즘을 사용하도록 JVM을 조정할 수 있다. (세부 사항은
JVM의 버전 및 공급업체에 따라 다르다.) 이러한 시간 소인을 바탕으로 가비지 콜렉션에 사용된 시스템
시간의 백분율을 계산할 수 있으며 더 나아가 다양한 JVM 설정을 비교할 수도 있다.
가비지 콜렉션 프로세스가 지속적으로 확장과 축소를 반복할 경우에는 JVM에서 확장 또는 축소 시기를
결정하는 데 사용하는 비율 즉, MinHeapFree 및 MaxHeapFree
값을 변경할 수 있다.
JVM의 발전에 따라 가비지 콜렉션과 관련된 JVM의 성능도 향상되고 있다. 현재의 조정 매개변수를 가장
잘 설명해 주는 문서는 JVM의 설명서이다.
조정 우선 순위
IBM에서는 WebSphere Application Server용 UNIX 서버를 조정할 때 확인해야 하는 영역에 대한 몇 가지 권장 사항을 제안하고 있다.
먼저 서버에 CPU, 디스크, 메모리, 네트워크 등의 리소스가 있는지 확인한다. 이러한 리소스는 기본적으로 갖추어져 있어야 한다.
그런 다음 애플리케이션의 가비지 콜렉션 요구 사항을 파악한 후 그에 맞게 JVM을 조정한다. 이를
수행하기 위해서는 이전 단계로 돌아가서 애플리케이션을 실행하는 데 필요한 메모리가 충분한지 확인해야
한다.
애플리케이션 서버 큐가 처리할 수 있을 정도의 요청만을 애플리케이션 서버에서 지원하는지
확인해야 한다. 웹 서버에서 애플리케이션으로 전달될 때 요청은 큐를 경유하므로 애플리케이션에
대한 연결을 너무 많이 허용하게 되면 모든 사용자가 경험하게 되는 성능이 떨어진다. 대신 웹
서버의 연결을 충분히 처리할 수 있을 정도로 큐의 용량을 확장하고 WebSphere Application Server와
분리한다.
마지막으로 데이터베이스의 준비된 명령문부터 EJB(Enterprise JavaBean) 기술 및 스레드 캐시에
이르기까지 많은 캐시가 사용된다. 새 항목을 위해 캐시의 공간을 늘려야 하는 상황이 지속적으로 발생할
경우에는 캐시를 확장해야 한다.
결론
컴퓨터의 리소스에는 CPU, 메모리, 디스크 및 네트워크가 있다. 조정 작업은
애플리케이션, 애플리케이션 서버 및 서버에서 이러한 리소스를 측정하여 리소스에
대한 경합이 발생하지 않도록 알맞게 조정하는 데 집중되어야 한다.
JVM은 자체적으로 관리하는 힙을 가지고 있으며 가비지 콜렉션이라는 프로세스를 통해
이 힙을 정리한다. 이 영역에서의 조정 작업은 힙을 애플리케이션에 필요한 크기로 확장할 수
있는지 확인한 후 가비지 콜렉션으로 인한 영향이 크지 않도록 가비지 콜렉션 매개변수를 조정하는
것이다.
가비지 콜렉션 조정에서는 각 가비지 콜렉션 활동을 기록하는 자세한 가비지 콜렉션 추적을
주로 사용한다. 이 로그를 통해 가비지 콜렉션의 주기와 가비지 콜렉션이 발생하는 이유를 판별할
수 있다.
참고자료 교육
제품 및 기술 얻기
필자소개 | 
| | Sean Walberg는 1994년부터 대학, 기업 및 ISP 환경에서 Linux 및 UNIX 시스템 작업을
수행해 왔으며 지난 수 년 동안에는 시스템 관리에 관한 글을 쓰고 있다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
