문]

시스템 성능 문제의 원인을 파악하기 위한 지침  

답]

이 문서는 시스템 성능 문제의 원인을 파악하기 위한 지침서입니다.
이 방법만으로는 일부 문제를 완전하게 진단하거나 정밀하게 조정된
시스템을 만들지 못할 수 있습니다. 

지원이 더 필요하면 시스템을 자세히 분석할 수 있는 HP 성능 분석 전문가를
이용하십시오. 성능 분석 컨설팅은 HP 레스판스 센터의 지원 범위를 벗어납니다.
HP 레스판스 센터 엔지니어는 추가 정보를 위해 성능 컨설턴트를 소개할 수
있습니다. 

개요 

시스템 성능이 떨어지면 대개 일부 자원이 부족한 것입니다. 문제가 시스템
자원 때문이면 CPU, 메모리, I/O 병목현상으로 분류할 수 있습니다. 시스템 
자원 문제가 아닌 자원 문제가 발생할 수 있으며, 이 경우 특정 응용 프로그램을
실행하거나 네트워크를 통해서만 시스템에 액세스할 때 성능 문제가 발생할 수
있습니다. 

이 문서에서는 시스템 자원의 병목현상이 있는지 여부를 판단하도록 도와 주고
문제를 해결하기 위해 수행할 수 있는 내용을 권장합니다. 

정확한 진단을 위해서는 시스템이 정상적인 성능을 낼 때의 기준 데이터를
확보해야 합니다. 

일반적으로 시스템 병목현상이 발생할 때 수행할 수 있는 조치는 다음
두 가지뿐입니다. 

-병목현상이 발생한 자원에 대한 요구 감소 

-사용 가능한 자원의 양 증가 

그러나 사용 가능한 자원의 양이 증가해도 시스템의 다른 자원 요청이 증가할
수 있기 때문에 성능이 눈에 띄게 개선되지는 않습니다. 예를 들어, CPU 한계에
이른 시스템에 프로세서를 추가하면 더 많은 프로세서가 CPU를 통해 실행하게
되어 추가 프로세서 부하를 처리하려고 할 때 메모리 또는 I/O 병목현상이
발생할 수 있습니다. 

성능 문제를 해결할 때 명심해야 할 사항이 있습니다. 다수의 병목현상이 
동시에 연쇄적으로 발생할 수도 있습니다. 

그리고 성능을 개선하기 위해 시스템을 변경할 때에는 한 번에 한 가지씩
수행해야 합니다. 

어떤 변경으로 문제가 해결되지 않으면 원래대로 복원하고 나서 다른 방법을
시도해야 합니다. 

도움은 되지만 문제가 완전하게 해결되지 않는 경우에는 일단 중단하고 새로운
데이터를 수집해야 합니다. 

시스템에 다수의 병목현상이 있는 경우 완화된 병목현상이 시스템 성능을
떨어뜨린 주범이 아닐 수도 있습니다. 예를 들어, 메모리 병목현상은 페이징
활동이 증가하기 때문에 CPU 또는 디스크 병목현상처럼 보일 수 있습니다.

-성능 평가 
버퍼 캐시 
자주 발생하는 한 가지 문제는 시스템이 정기적으로 1초, 2초 또는 30초 이상
서 버리는 것입니다. 이 경우, 원인은 대개 syncer 프로세스가 30초마다 손상된
페이지를 삭제하는 대형 버퍼 캐시입니다. 기본적으로 10.X에서는 버퍼 캐시가
동적 캐시이므로 주 메모리의 50%까지 차지하도록 확장할 수 있습니다. 이러한
시스템 정지가 발생하는 시스템에서 버퍼 캐시를 더 작은 값(메모리의
10%부터)으로 설정하고 제3부에서 설명한 대로 버퍼 캐시를 조정하면 이 성능
문제가 해결될 수 있습니다. 

CPU, 디스크, 메모리, 네트워킹 병목현상의 징후 
아래에 설명하는 각 징후에 대해 몇 가지 확인 방법을 추천합니다. 명령과
출력에 대한 자세한 내용은 해당 온라인 설명서에서 찾아볼 수 있으며 잠깐
표시되는 특정 필드의 의미를 설명하는 데에는 Glance 도움말 화면이 가장
유용할 것입니다. 모든 문제를 해결할 수 있는 도구는 없습니다. 시스템 성능의
정확한 상황을 파악하려면 여러 도구를 함께 사용해야 합니다.

CPU 병목현상 
        -유휴 CPU 시간 0%(sar -u, top)
        -유휴 시간 0%, 시스템 CPU 시간에 비해 높은 사용자 CPU 시간 비율
          (sar -u, top) 
        -오랫동안 큰 실행 대기열 크기 유지(vmstat 5 30, uptime) 
        -우선순위에 따라 많은 프로세스 차단(Glance) 
        -느린 응답 시간 
        -높은 시스템 CPU 시간 비율(sar -u, top) 

디스크 병목현상 
        -높은 디스크 이용률(sar -d, iostat, Glance) 
        -큰 디스크 대기열 길이(sar -d, iostat, glance) 
        -높은 %wio(sar -u) 
        -낮은 버퍼 캐시 접속률(sar -b) 
        -유휴 CPU의 큰 실행 대기열(vmstat 5 30) 

메모리 병목현상 
        -오랫동안 높은 page_out_ rates, 페이징은 정상(vmstat 5 30) 
        -소수의 사용 가능 및 활성 가상 메모리 페이지(vmstat 5 30) 
        -스왑 디스크에서의 높은 디스크 활동(sar -d, glance, iostat) 
        -메모리 부족 오류 
        -vhand에 주어진 CPU 시간(및 9.X의 스와퍼) (ps -ef, top, Glance) 
        -시스템 대 사용자 프로세스에 주어진 과도한 CPU 시간 

CPU, 메모리 또는 디스크 병목현상의 흐름은 다음과 같습니다. CPU 사용을
확인하는 1단계를 시작으로 CPU, 메모리 또는 디스크 병목현상을 진단하는
지침이 이어집니다. 아래의 각 단계에서 시스템 성능이 떨어질 때 수집된
데이터로부터 오랜 시간에 걸친 동향을 파악합니다. 또한 이 데이터를 시스템
성능이 좋을 때 수집한 데이터와 비교해야 정확한 진단이 가능합니다.

1단계 
        sar -u  

%idle이 낮습니까? 이것은 CPU가 프로세스를 실행하지 않는 시간 비율입니다.
오랫동안 %idle이 0이면 CPU 병목현상의 첫 번째 징후일 수 있습니다. 

        No  - >  시스템이 CPU 한계에 이르지 않음. 3단계로 이동합니다. 
        Yes - >  시스템이 CPU, 메모리 또는 I/O 한계에 이르렀습니다. 2단계로
               이동합니다. 

2단계 
%usr가 높습니까? 많은 시스템은 CPU 시간의 80%를 사용자 시간으로 소비하고
20%를 시스템 시간으로 소비할 때 정상 작동합니다. 다른 시스템은 정상적으로
80% 내외의 사용자 시간을 사용합니다.

        No  - >  시스템에 CPU, 메모리 또는 IO 병목현상이 있을 수 있습니다.
               3단계로 이동합니다. 
        Yes - >  시스템에 사용자 프로세스 때문에 CPU 병목현상이 발생한
               것같습니다. "CPU 병목현상이 있는 시스템 조정"으로
               이동합니다. 

3단계 
%wio가 15보다 큽니까? 

        Yes - >  나중에 이 사실을 기억합니다. 병목현상에 빠진 디스크 또는
               테이프가 있다는 징후입니다. 4단계로 이동합니다. 
        No  - >  4단계로 이동합니다. 

4단계

        sar -d  

디스크에 대한 %busy가 50보다 큽니까? 50%는 대략적인 기준이며 "시스템의
수치가 정상보다 훨씬 큽니까?"가 더 나은 질문일 것입니다. 

%busy 값 20가 디스크 병목현상을 나타내는 시스템이 있는가 하면, 50%인
디스크가 정상인 시스템도 있습니다. 

이 디스크에서 avwait  >  avserv입니까? 

        No  - >  디스크 병목현상이 아닐 가능성이 높으므로 6단계로
               이동합니다. 
        Yes - >  이 장치에 I/O 병목현상이 있는 것같습니다. 5단계로
               이동합니다. 

5단계 
시스템에 디스크 병목현상이 있습니다. 병목현상을 일으키는 디스크에 무엇이
있습니까? 

        원시 파티션, 파일 시스템 - >  "디스크 I/O 한계에 이른 시스템에서
        시스템 조정"으로 이동합니다. 
        스왑 - >  메모리 병목현상 때문일 수 있음. 6단계로 이동합니다. 

6단계 

        vmstat  

오랫동안 po가 0보다 큽니까? S800 시스템의 경우 (free * 4k)  <  2 MB입니까?
S700 시스템의 경우 free * 4k  <  1 MB입니까? 값 2 MB와 1 MB는 대략적인
기준이며 시스템이 페이징을 시작하는 실제 LOTSFREE 값은 시스템 부팅 시
시스템 메모리의 크기에 따라 계산됩니다. 

        No  - >  1단계에서 %idle이 낮았으면 시스템이 CPU 한계에 이른
               것입니다. "Section 3, Part A, CPU 한계에 이른 시스템"으로
               이동합니다. %idle가 낮지 않았으면 CPU, 디스크 I/O 또는
               메모리 병목현상이 아닌 것같습니다. "기타 병목현상"으로
               이동합니다. 
        Yes - >  시스템에 메모리 병목현상이 있습니다. "메모리 한계에 이른
               시스템 조정"으로 이동합니다. 

-시스템 병목현상 조정 
다음은 병목현상에 빠진 자원에 대한 요구를 줄이거나 병목현상의 영향을
변경(덜 중요한 프로세스를 사용 중인 자원에 중요한 프로세스를 지정하여 더
중요한 프로세스를 보다 빨리 실행시키고 덜 중요한 프로세스는 좀더 느리게
실행)할 수 있는 몇 가지 방법입니다.어떤 방법이 시스템에 따라 눈에 띄는
결과를 낼 수도 있고 거의 효과가 나타나지 않을 수도 있습니다. 

모든 상황에 좋은 효과를 내는 방법은 없습니다. 시스템 하드웨어 업그레이드가
가장 경제적인 해결 방법인 상황도 있습니다. 

다음 방법으로 문제가 해결되지 않는 상황도 있습니다. 가끔 소프트웨어
방식으로는 도저히 해결되지 않아 하드웨어 업그레이드가 필요한 경우도
있습니다. 각 상황에 대한 자세한 방법을 알려면 성능 컨설턴트를 이용하십시오. 

-CPU 한계에 이른 시스템 조정 
시스템이 CPU 한계에 이르렀을 때 먼저 고려할 사항은 "CPU를 공정한 비율보다
많이 차지하는 특정 프로세스, 프로세스 그룹이 있는가?"하는 것입니다.
각 프로세스가 CPU를 사용 중인 비율은 전체 프로세스 화면의 Glance에서 확인할
수 있습니다. 맨 위에 이 정보가 나타납니다. ps -ef 명령으로 만든 실행
프로세스의 목록에는 각 프로세스가 실행된 이후 누적 CPU 시간이 나타납니다. 

어떤 프로세스는 다른 프로세스보다 더 큰 CPU 시간을 차지해야 합니다.
예를 들어, 대부분의 경우 백업을 완료하는 것보다는 응용 프로그램에서 적시에
응답을 받는 것이 두세 배 더 중요합니다. 

아래에 CPU 사용을 제어하는 몇 가지 방법을 소개합니다. 다음 명령에 대한
자세한 내용은 해당 온라인 설명서를 참조하십시오. 

        -사용량이 적은 시간 동안 오래 걸리는 배치 작업 실행 
        -덜 중요한 응용 프로그램에 대한 nice(1) 
        -중요한 프로세스에 plock(2) 사용. 이렇게 하면 시스템의 다른
         프로세스에 메모리 병목현상이 발생할 수도 있습니다. 
        -시스템 계정 및 감사 기능 끄기 
        -Taskbroker 또는 DCE 사용 고려 
        -부가 가치 작업 스케줄러 Process Resource Manager 사용 고려 
        -CPU 시간의 많은 부분을 사용 중인 응용 프로그램 최적화. 단, 이
         방법은 시스템 CPU를 업그레이드하는 것보다 비용이 더 많이 들 수
         있습니다. 
        -Xstation 대신 NFS diskless 클라이언트(자체의 CPU 보유) 사용 

-디스크 I/O 한계에 이른 시스템 조정 
이 시점에서 실제 디스크 메커니즘 병목현상과 버스 컨트롤러 병목현상을 
구별할 수 없습니다. 그러한 내용을 결정하려면 외부 장치를 사용해야 합니다. 
이 점에 유념하여 디스크 병목현상을 완화하기 위한 과정을 수행해야 합니다.

어떤 장치의 I/O 사용이 많은 파티션 판별은 Glance에서 수행할 수 있으며,
Logical Volume 화면에서 가장 쉽게 수행할 수 있습니다. 

        -병목현상이 스왑 파티션에 있으면(불가피한 메모리 병목현상 때문에
         발생) 동일 크기와 동일 우선순위의 여러 스왑 영역을 사용하여 여러
         스핀들/버스에 걸쳐 I/O를 고루 분배합니다. 
        -여러 스핀들/버스에 디스크 I/O 균일하게 분배 
        -버퍼 캐시 크기 조정(증가), 파일 시스템에만 적용됩니다. 
        -온라인 JFS를 사용하는 경우 fsadm으로 파일 시스템 조정 
        -파일 시스템에 사용 가능한 공간이 많을수록 구조에 데이터를 더
         효과적으로 배치할 수 있습니다. 
        -디스크 그룹을 특정 응용 프로그램 전용으로 지정하고 해당 디스크
         그룹에 걸쳐 응용 프로그램용 I/O를 균일하게 분배 
        -파일 시스템을 만들 때 mkfs(1m) 옵션 사용. 특정 용도를 염두에
         두고 파일 시스템을 만들 수 있습니다. 예를 들어, 실린더 그룹과
         inode가 많은 파일 시스템은 작은 파일이 많을 때 가장 효율적인
         검색 시간을 제공하는 파일 시스템 구조 위치에 파일을 배치하도록
         설계됩니다. 
        -비동기 I/O 사용(커널 매개변수 fs_async) 고려. 비동기 I/O를
         사용하면 시스템 크래시가 발생할 때 데이터가 없어질 가능성이
         커집니다.
        -즉시 보고 사용 고려. scsictl 명령 또는 10.x의 경우 커널 매개변수
         default_disk_ir로 제어합니다. 이 방법도 시스템 크래시가 발생할 때
         데이터가 없어질 가능성이 커지는 위험한 방법입니다. 
        -기호 링크 최소화 
        -파일 시스템을 만들 때 가능하면 파일 시스템 블록 크기를 파일 
         크기와 일치하게 지정 
        -9.x의 경우 tunefs 명령으로 회전 지연 시간을 사용하지 않도록 파일
         시스템 조정. 파일 지연 시간이 변경된 후 작성한 파일의 배치에만
         적용됩니다. 
        -시스템의 파일에 액세스하기 위해 긴 디렉토리 경로를 자주 사용하는
         경우 ninode 증가 

-메모리 한계에 이른 시스템 조정 
먼저, 대량의 메모리를 사용하는 프로세스를 확인합니다. Glance에서는 전체
화면에서 가변 RSS가 사용 메모리 양을 나타냅니다. ps -ef 목록에서 SZ 열은
사용 메모리의 양을 나타냅니다. 

        -잠긴 메모리 양 감소. 커널 매개변수 unlockable_mem으로 잠글 수 
         있는 메모리 양을 제한합니다. 
        -불필요한 창 닫기. 쉘 시간 종료가 도움이 됩니다. 
        -메모리 리크(차지하는 메모리 양이 점점 커지는 것)가 있는 프로그램
         확인 -파일 시스템 버퍼 캐시 조정(크기 감소) 

-파일 시스템 버퍼 캐시 조정 
파일 시스템 I/O 병목현상 또는 메모리 병목현상이 문제인 것으로
결정되었습니다. 어느 경우든 버퍼 크기를 조정하면 문제가 해결될 수 있습니다. 
버퍼 캐시가 주 메모리의 5%에서 50% 크기인 10.X의 동적 버퍼 캐시 기본값이
아닌 고정 크기이면 버퍼 캐시의 효과와 변경의 효과를 측정하기 쉽습니다.
버퍼 캐시의 크기는 커널 매개변수 bufpages, nbuf, dbc_max_pct, dbc_min_pct에 
의해 제어됩니다. 이 매개변수에 대한 자세한 내용은 SAM 도움말, 커널 재설정
방법에 대한 자세한 내용은 System Administration Tasks 설명서를
참조하십시오. 전통적으로 HP-UX는 주 메모리의 10%를 버퍼 캐시 크기
기본값으로 사용해 왔습니다.

버퍼 캐시의 목표는 디스크 I/O 읽기 및 쓰기의 속도를 높이는 것입니다. 성능
향상과 주 메모리 사용 비율을 잘 절충해야 합니다. 시스템 속도를 떨어뜨리는
자원을 격리시킨 후 이 시스템에서 가장 좋은 효과를 내도록 버퍼 캐시 크기를
조정해야 합니다.

# sar -b  
%rcache  > = 90, %wcache  > = 70%가 적당합니다. 일부 시스템 구성(예: 원시
파티션 또는 무작위의 읽기 및 쓰기를 수행하는 응용 프로그램이 있는 
시스템)에서는 이 버퍼 캐시 접속률이 나타나지 않습니다. 목표는 특정
시스템에서 최상의 성능을 내도록 캐시를 조정하는 것입니다. 고정된 버퍼 캐시
크기로 시작하여 캐시를 더 크거나 작게(예를 들어, 한 번에 2%씩) 조정합니다.
그런 다음 결과를 측정합니다. 접속률이 증가/감소했으며, 결과는 메모리 
사용을 변화시킬 만합니까?

두 가지에 유념해야 합니다. 버퍼 캐시를 조금씩 증가/감소시킬 때 %rcache와
%wcache가 변하지 않으면 이 조정이 아무 의미도 없으며 파일 시스템 I/O
성능에도 나쁜 영향을 끼치지 않습니다. 또한 모든 시스템은 서로 다른
읽기/쓰기 접속률을 나타냅니다. 아주 높은 접속률이 결코 나타나지 않는
시스템도 있습니다.

-기타 병목현상 
성능 문제의 다른 원인으로 네트워크, 응용 프로그램 자체 또는 디스크
드라이브를 제외한 시스템 주변 장치가 있습니다. 다른 I/O 병목현상의 징후로
iostat와 glance에 나타나는 높은 I/O 활동 또는 극심한 처리 능력 저하가
있습니다.

네트워킹 병목현상은 glance, Network by Interface 화면, 높은 충돌 횟수로
나타날 수 있습니다. 시간 종료 요청, 재시도, 패킷 오류도 네트워크 병목현상의 
징후입니다. netstat 명령으로 네트워크 병목현상을 진단할 수도 있습니다.

데이터베이스는 대량의 CPU, 메모리, 디슨크 I/O를 소모합니다. 응용 프로그램
실행 속도가 느려지는데 시스템에 자원 병목현상이 발생하지 않는 경우
응용 프로그램 관리자가 주목해야 할 몇 가지 사항이 있습니다.

CPU 사용이 많은 프로세스를 식별한 다음 서로 다른 nice 값으로 CPU 시간을
더 많거나 작게 지정하는 것이 좋습니다. 

클라이언트 부하가 여러 시스템에 걸쳐 분포할 수 있습니다. 원시 파티션을
사용하는 경우 최상의 메모리 및 I/O 균형을 얻도록 응용 프로그램의 I/O 캐시를
조정해야 합니다. 디스크 I/O를 최상으로 사용하려면 로그, 테이블, 인덱스의
위치를 세심하게 고려해야 합니다. 그러면 코드에 세마포어 사용이 감소할 수
있습니다. 

응용 프로그램이 사용 중인 공유 메모리 크기를 최적화할 수 있습니다. 또한
데이터베이스는 응용 프로그램 속도를 떨어뜨리는 잠금을 많이 사용하여
deadlock이나 dirty read가 발생할 수 있습니다. 잠금 사용을 최소화해야
합니다.