Digital Recipe
[요약본] Linux System Performance 본문
Last Update : 2016. 05. 08
이 게시글은 위 발표자료의 쉬운 이해를 위한 요약본 형태로 작성되었습니다.
이 발표자료는 리눅스 성능의 6가지 측면을 다룹니다.
1. 확인 가능한 요소들
2. 방법론
3. 벤치마킹
4. 수집 (시간별 리소스의 상태변화를 수집)
5. 추적 (이벤트별 수행시간을 측정)
6. 최적화
1. 확인 가능한 요소들
리눅스의 아키텍처이다. 운영체제를 구성하는 CPU 스케쥴링, 가상 메모리, 파일 시스템, 네트워크 등이 존재하고 각 역할마다 그 상태를 확인할 수 있는 리눅스 유틸리티 도구를 소개하고 있다.
이러한 도구들은 각 역할에 맞게 일반적인 평가요소를 보여준다.
또한 이런 도구외에도 다양한 추가적인 평가 도구들이 존재한다.
예를 들면, uptime이라는 도구가 있다. 이 도구는 CPU와 디스크에 대한 리소스 요구가 어떻게 수행되었는지 보여준다.
2. 방법론
이제 저런 도구를 이용해서 어떻게 성능을 평가할 것인지 알아보자.
여기서 소개하는 방법론은 아래와 같다.
- 60초 동안의 리눅스 성능 분석
- USE Method(Utilization, Saturation, Error)
- CPU 상태 수집
- 리소스 분석
- 워크로드 분석
- 기타 등등...
성능을 평가하는데 중요한 요소는 특정시간 내의 상태변화이다. 각 도구를 60초 동안 수행하여 각각의 상태변화를 수집하거나 60초 동안의 평균값을 수집한다.
USE Method는, 리눅스를 평가하기 위한 활용도, 포화도(혹은 과부하), 오류에 대한 평가 방법론이다.
여기서 활용도란 실제 동작했던 시간을 말하며, 포화도는 처리속도가 요구속도가 느려서 처리가 지연되는 시간을 말한다.
CPU 상태 수집은 CPU의 변화를 통해 직접적으로 CPU 사용률을 확인하거나 간접적으로 I/O와 같은 부분을 확인할 수 있다.
리소스 분석은 시스템 성능 분석을 위한 일반적인 접근방법이다. 장점으로 리소스 성능 최적화를 목적으로 할 수 있다. 단점으로 잘못된 것을 정상적으로 생각(False Positive[REF.03])할 수 있다.
워크로드 분석은 어플리케이션을 통해 분석하는 것이다. 정확하고 적절한 평가요소를 가질 수 있으나 어플리케이션에 의존적이고 어플리케이션에서 리소스 사이의 동작을 들여다 볼 수 없다.
3. 벤치마킹
관찰 가능한 분석을 떠나서, 벤치마킹은 실험적 분석을 위해 유용하다. 하지만 에러에 취약하다. 예를 들면 잘못된 대상을 테스트 할 수 있고 유효하지 않은 결과를 나타내기도 한다.
벤치마킹은 각 역할별 테스트하는 마이크로 벤치마크와 요청에 대한 결과를 테스트하는 매크로 벤치마크가 있다. 주의할 점에는 패러독스[REF.02]에 빠질 수 있는데 대표적으로 제품이 벤치마크를 50:50 비율로 이기게 되어 있어도 벤치마크가 테스트를 잘못 이끌 확률이 높기 때문에 대부분 지게된다고 표현하고 있다. 이런 이유로 제대로된 벤치마킹을 위해서는 벤치마크가 동작하는 중 실제 원인에 대한 성능 분석이 필요하다.
4. 수집
특정 시간마다 상태변화를 수집하여 시간에 따른 각 리소스의 평균적인 상태를 분석하는 것이다.
이런 상태변화를 수집하기 위한 perf_events와 같은 더욱 특별한 도구들이 있다.
5. 추적
수집과 유사하다. 평가 대상이 리소스가 아니라 이벤트인 것이 다르다. 추적은 발생된 이벤트 별로 수행된 시간이나 응답시간등을 통해 성능 평가가 가능하다. 위 그림은 이벤트 추적을 통해 평가해야 하는 요소를 나타낸 것이다.
6. 최적화
각 운영체제의 환경요소를 바꿔서 성능을 향상시킬 수 있다.
Written By Hoseok Seo
2016. 05. 02
REFERENCE
01. http://www.slideshare.net/brendangregg/linux-systems-performance-2016
02. http://www.brendangregg.com/blog/2014-05-03/the-benchmark-paradox.html
03. http://seohs.tistory.com/375
