[실무로 배우는 시스템 성능 최적화] 서버 모니터링

기본 방향

서버 자원 사용률 확인 시 중간 점검 항목

CPU

Memory

Disk

Network

자원 모니터링 로그를 남겨서 분석 시

CPU

사용량 분석

안정적인 운영을 위한 CPU 사용률 기준

CPU 사용량 상세 분석

가상화 CPU 사용률

Memory

메모리 부족과 성능 영향

운영체제 측면의 메모리 부족 여부와 성능 영향도

자바 기반 솔루션의 경우

오라클 버퍼캐시처럼 데이터 베이스의 경우

가상 메모리

주요 개념

사용량 분석

안정적 운영을 위한 메모리 판단 기준

일반적인 메모리 사용률 산출

1. 파일 캐시

2. IPC(Inter-Process Communication)

3. 프로세스

 

 

기본 방향

---

서버 자원 사용률 확인 시 중간 점검 항목

일반적으로 CPU → Memory → Disk → Network 순으로 부족 여부를 확인한다

CPU

• CPU 자원은 부족한가?

• 실행큐에 얼마나 쌓였는가?

• CPU 사용 유형 중 System이나 IO wait의 사용률이 높은가?

• 프로세스별 CPU 사용률 분포는 균등한가?

Memory

• 메모리가 부족한가? (swap이 발생하고 있는가?)

• 서버 전체 또는 개별 프로세스 단위로 메모리 사용량이 지속적으로 증가하는가?

• 파일 캐시 영역으로 사용하는 메모리량은 얼마인가?

Disk

• 디스크의 서비스 시간은 디스크 대기시간을 포함해서 얼마인가?

• 특정 디스크로 입출력이 집중됐는가?

• 파일시스템 중 공간이 부족한 곳은 있는가?

• 디스크 스트라이프가 잘 구성돼 있는가?

• 스토리지 채널 병목이 있는가?

Network

• 네트워크 데이터 전송량은 얼마인가?

• 네트워크 재전송량이 많은가?

• RTT(Round-Trip time) 시간이 높은가?

 

자원 모니터링 로그를 남겨서 분석 시

• 자원 모니터링은 5초나 10초 간격으로 한다.

• 자원 사용률 분석은 그래프를 통해 분석하는 것이 효과적이다.

• 자원 사용률은 프로세스와 연관시켜 분석하는 것이 좋다.

 

 

CPU

---

사용량 분석

안정적인 운영을 위한 CPU 사용률 기준

• CPU 사용률 70% 이하

• CPU 실행 큐 : CPU(코어)당 평균 3개 이하

전체 CPU 기준으로 성능 평가를 할 때는 이중화 구성 등에 따른 부분 장애시에 대한 변화량/사용량을 맞춰서 판단할 필요가 있다.

CPU 사용량 상세 분석

• System : 커널 모드 시스템 콜 호출에 사용된 CPU 사용량이다. 시스템 콜은 일과 네트워크의 관리와 입출력 처리, 시스템 정보와 시간 관리 등에 관련된 함수다.

• User : 일반 함수를 실행하는 데 사용된 CPU 사용량이다.

• IO Wait : 프로세스나 스레드가 CPU를 할당받아 사용할 수 있는 상태가 됐으나 현재 입출력이 완료되기를 기 다라고 있어 CPU를 사용할수 없는 상태의 사용량이다.

• Idle : 사용하지 않는 CPU 여유율이다.

가상화 CPU 사용률

• 동적 파티션(Dynanic partition)을 구성하면서 각 파티션의 CPU 최대 사용량 합이 100%를 넘게 설정한 경우에는 모니터링 도구에 보이는 CPU 사용률이 100% 이하지만 실제는 CPU 를 100% 사용해 병목이 발생하고 있을 수도 있다.

 

Memory

---

메모리 부족과 성능 영향

운영체제 측면의 메모리 부족 여부와 성능 영향도

• 페이징 스페이스에 대한 스왑 발생 여부로 판단하며, 추가로 메모리는 각 소프트웨어 솔루션의 메모리 사용 방식을 이해하고 성능을 분석하는 작업이 필요

자바 기반 솔루션의 경우

• 설정한 최대 힙 메모리 이상을 사용하지 않기 때문에 최대 힙 메모리가 운영체제의 메모리 부족이 발생할 가능성은 낮다.

• 한정된 힙 메모리 내에서 동작하기 때문에 대량의 데이터 처리와 빈번한 GC로 인한 성능 저하가 유발될 가능성이 있다.

• 힙 메모리를 과하게 크게 설정한 경우에는 메모리를 청소하는 GC작업으로 순간 순간 멈추는 시간이 길어져 서비스 안정성이 떨어질수 있다.

오라클 버퍼캐시처럼 데이터 베이스의 경우

• 메모리에 최근에 사용한 데이터 블록을 캐시해서 재사용하는 알고리즘

1. 캐시의 메모리 크기가 너무 적게 설정된 경우
   • 캐시 적중률이 떨어져 디스크에서 데이터 블록을 읽어와야하는 빈도가 늘어나 성능 저하 유발

2. 캐시를 크게 설정해 운영체제에서 스왑이 발생하게 되면
   • 오히려 작게 설정한 것보다 성능이 더욱 악화되어 서비스가 거의 멈추는 상태 유발

 

가상 메모리

메모리 사용 패턴이 100%라고 해도 부족하지 않으면 성능저하가 발생하지 않는다.

주요 개념

1. 페이징 스페이스(Paging Space)
   • 운영체제는 상대적으로 값싼 디스크를 보조 메모리로 사용하는 방식을 사용하고 있다. 디스크의 일정공간을 할당해 보조 메모리 용도로 사용
   • 페이징스페이스는 메인 메모리가 부족할 때 사용하는 디스크 공간으로, 스왑스페이스라고도한다.
   • 시스템 성능 관점에서 보면 페이징 스페이스는 디스크에 프로세스 메모리를 쓰고, 읽는 스와핑 작업으로 인해 메모리 접근만으로 처리될 때에 비해 큰 성능 저하가 발생한다. 따라서 스와핑이 발생하지 않도록 메모리 여유율을 유지하는 것이 성능에 중요하다.

2. 스와핑(swapping)
   • CPU 사용 빈도가 낮은 프로세스의 메인 메모리 사용 부분을 페이징 스페이스 부분으로 옮겨 여유 메모리를 확보한 후 사용할 페이징 스페이스 부분을 메인 메모리로 로드해서 사용
   • 프로세스가 사용하는 메모리 일부를 페이징 스페이스로 옮기거나 페이징 스페이스로부터 메모리로 로드하는 것을 가리킨다.
   • 주요 용어

     • 페이지 부재(Page Fault) : 페이징 방식의 가상메모리에서 CPU가 사용하려는 페이지가 메인 메모리에 없는 경우다. 사용하려는 가상 메모리 주소에 해당하는 페이지를 매핑 테이블에서 주소 변환할 때 해당 페이지가 메인 메모리에 없다고 표시되어 있으면 페이지 부재가 발생한다.

     • 페이지 인(Page In) : 가상 메모리에서 페이지 부재가 일어났을 때 디스크에 있는 프로그램이나 데이터를 메모리로 로드 하는 것이다.

     • 페이지아웃(Page Out) : 가상 메모리에서 페이지 부재가 발생했을 때 메모리가 부족하면 페이지스틸러(Page stealer)는 기존 메모리를 디스크로 기록하는 페이지 아웃이라는 작업을 수행한다.

       기록 대상 메모리가

       1. 프로세스의 작업세그먼트(Work segment)영역에 있는 메모라면,
          → 페이징 스페이스로 기록하고,
       2. 파일에서 읽어들인 내용(Permanent segment)인 경우
          1. 페이지의 내용이 변경됐으면 디스크의 해당 파일에 기록하고
          2. 그렇지 않으면 소멸시킨다.

     • 페이지 스캔율(Page Scan Rate) : 운영체제는 일정량의 여유 페이지(Free page)를 확보해서 필요할 경우 즉시 제공하기 위해 페이지 스캔(Page scan)이라는 검색을 통해 해제함으로써 여분으로 확보할 페이지를 찾는다. 여유 페이지 목록(Free page list) 임계치보다 여유 페이지 수가 줄어들면 메모리 관리자는 기존의 페이지 인(Page In)된 것 중에서 LRU 알고리즘 검색을 통해 페이지 아웃이 가능한 것을 찾아 페이지 아웃시킨 후 여유 페이지로 변경한다.

       → 여기서 페이지 아웃이 가능한 페이지를 탐색하는 빈도를 의미하는 페이지 스캔률이 나오는데 이 빈도가 높다는 것은 해제할 페이지가 넉넉하지 못하기 때문에 자주 메모리를 탐색해야 한다는 의미로 볼 수 있다.

3. 활성 가상메모리(Active virtual memory)
   • CPU가 직접 접근할 수 있는 메인 메모리

4. 비활성 가상메모리(Inactive virtual memory)
   • 페이징스페이스

5. 가상메모리 주소
   • 프로세스 내에서만 유효한 주소다. 각 프로세스는 가상메모리 주소와 실제 주소 간의 매핑테이블을 가지고 있어 가상메모리 주소로 실제 주소를 찾아갈 수 있게 돼 있다.

6. 실제 메모리 주소
   • 메인 메모리와 페이징 스페이스의 주소.

 

사용량 분석

서버메모리는 용도에 따라 파일캐시, IPC, 프로세스 메모리로 나뉜다. 따라서 메모리가 부족한 것으로 모니터링되어 사용량을 줄여야 한다면 세가지 부분으로 나뉘어 메모리 사용량을 분석해 줄일 수 있는 부분을 찾아야 한다.

안정적 운영을 위한 메모리 판단 기준

• 메모리 사용률 100% 이하

• 지속적으로 프로세스 스와핑이 발생하면 메모리 부족 (페이지 스캔률이 지속적으로 발생하면서 페이지 아웃이 발생하는 상태)

일반적인 메모리 사용률 산출

• 전체 메모리 total : used + free + buffers + cached

• 실제 free 메모리 : free + buffers + cached

• 실제 메모리 사용량 : total - (free + buffers + cached)

 

1. 파일 캐시

파일 캐시는 운영체제에서 디스크 입출력 성능 개선을 위해 사용한 파일을 메모리상에 캐시해 디스크 입출력을 줄이는 것이다. 파일캐시에서 성능상 문제가 생기는 것은 캐시를 전체 운영체제 메모리 대비 너무 많이 사용함으로써 프로세스가 사용할 메모리가 부족한 상황이 발생하는 것이다. DB 서버는 데이터 버퍼(Data Buffer)라는 내부 캐시가 있어 운영체제 파일 캐시를 크게 설정할 필요가 없고, 특히 Raw device를 사용한다면 파일 캐시를 사용하지 않으므로 설정해도 성능 개선이 되지 않는다.

오히려 메모리 부족 현상으로 DB 사용 메모리가 페이징스페이스로 내려가는 상황이 발생하면 급격한 성능 저하가 발생한다. WAS 서버의 경우에도 파일 카시에 의한 성능 개선 사례는 지금까지 경험한 적이 없을 정도로 성능에 큰 영향을 미치지는 않는다.

따라서 파일 캐시는 전체 메모리 대비 최대 크기를 30% 이하로 유지 하는 것을 권고한다. 파일 캐시 크기는 최솟값과 최댓값으로 설정하는데 최솟값까지는 프로세스가 사용하는 메모리가 부족한 상황이 되면 파일 캐시가 사용하는 메모리를 프로세스용으로 반납한다.

 

2. IPC(Inter-Process Communication)

IPC는 프로세스 간에 데이터를 공유하거나 통신할 때 사용하는 여러 방식을 통칭하는 용어다.

프로세스 간 메시지 전송 동기화, 데이터 공유, 원격 프로시저 호출 용도로 분류해 파일 파이프, 소켓, 메시지 큐, 세마포어, 공유 메모리, 메모리 맵드 파일 등이 있다. 이 가운데 대표적으로 프로세스 메모리와 분리되어 메모리를 사용하는 대표적인 IPC가 메시지 큐, 세마포어, 공유 메모리다.

 

3. 프로세스

프로세스 파일 캐시와 IPC용으로 사용 중인 메모리를 제외하면 대부분은 프로세스가 직접 사용하는 메모리다. 그래서 메모리가 부족할 때는 IPC나 파일 캐시도 보지만 어떤 유저와 프로세스 유형들이 메모리를 많이 사용하는지 분석한다.

오라클 DB를 예로 들면 IPC인 공유메모리를 사용하는 SGA(System Global Area)가 가장 많은 메모리를 사용하겠지만 그에 못지 않게 개별DB 처리 프로세스가 사용하는 PGA(Program Global Area) 메모리 사용량이 많다. 대형 시스템의 경우 DB 서버 한 대에 수천 개의 DB 연결이 맺어져 있는 경우도 있는데 DB 프로세스 하나가 10MB씩만 메모리를 사용해도 수십 GB에 달하는 메모리가 사용된다. 이 상황에서 메모 리가 부족하다면 SGA의 메모리 축소 가능성도 검토하겠지만 먼저 DB 연결 수를 줄여서 메모리를 절약하는 방안을 검토할 것이다.