서버/인프라를 지탱하는 기술 Ch.4의 내용과 Load Average에 대해 정리하고자 한다.
단일 서버의 성능
을 충분히 끌어낸 다음 서버를 추가하는 방법을 고민해야 한다.단일 호스트의 성능을 끌어내는 데에는 서버 리소스의 이용현황을 정확하게 파악할 필요가 있다.
MySQL과 같은 애플리케이션의 부하를 먼저 떠올리겠지만, 대상이 되는 것은 그 하위에 있는 OS이다.
부하를 알기 위해 필요한 모든 정보는 OS, 리눅스 커널이 지니고 있다.
ps, top, sar 등의 툴 사용
-> 원인을 추측하지 말고 계측하여야 한다.
Load Average란 ?
평균적으로 어느 정도의 Task가 대기 상태로 있었는지를 보고하는 지표
이다.CPU 코어 수에 따라 숫자가 달라지며, CPU 코어가 100% Load가 발생할 경우
1코어는 값 1, 2코어는 값 2로 표현된다.
1코어에서 Load Average가 2라면, 100%는 로드된 상태 100%는 대기하는 상태를 의미한다.
-> top, uptime의 명령으로 확인할 수 있다.
부하란 ?
대기 시간
이다.프로세스 스케줄러에 의해 가질 수 있는 프로세스 상태는 다음과 같다. ( 간략히 )
TASK_RUNNING : 실행 가능한 상태 -> R(Running)
TASK_UNINTERRUPTIBLE : 디스크 입출력 대기, 중단 불가능 -> D(Uninterruptible wating)
TASK_INTERRUPTIBLE : 키보드 입력 대기, 중단 가능
다음 그림과 같은 상황일 때, Ready queue에서 대기하거나, Waiting queue에서 네트워크 또는 디스크 I/O 작업으로 인해 대기해야 하는 시간이 부하라고 볼 수 있다.
-> 프로세스 입장에서 요청에 대한 응답이 올 때 까지 아무것도 할 수 없다.
-> 해당 상태가 많으면, 특정 요청이 끝나기를 기다리는 프로세스가 많다는 것으로 부하 계산에 포함된다.
Ready queue -> CPU의 실행 권한이 부여되기를 기다리고 있는 프로세스
Waiting queue -> 네트워크 또는 디스크 I/O가 완료하기를 기다리고 있는 프로세스
반면, TASK_INTERRUPTIBLE ( 사용자의 특정 행동을 기다리고 있을 경우) 에는 사용자가 동작을 하고 있지 않은 것이니 Load Average 계산에 포함되지 않는다.
Load Average는 시스템 전역변수 배열
에 평균 4ms 마다 인터럽트를 주며 결과를 저장하고 있는다.
Load Average는 어디까지나 대기 Task 수 만을 나타내는 수치이므로,
Load Average만으로는 CPU 부하가 높은지, I/O 부하가 높은지는 판단할 수 없다.
sar
를 통해 관측할 수 있다.
멀티 CPU가 탑재되어 있더라도 디스크는 하나밖에 없는 경우
CPU 사용률
Load Average는 어디까지나 시스템 전체 부하의 지표가 되는 값으로, 그 이상 자세한 분석이 불가능하다.
CPU 사용률이나 I/O 대기율은 전체의 합계로 보고되지만 개별적으로 확인할 수 있고, 그럴 필요가 있다.
CPU 부하가 높은 경우
I/O 부하가 높은 경우
프로그램 오류로 메모리를 지나치게 사용하고 있는 경우에는 프로그램을 개선
탑재된 메모리가 부족한 경우에는 메모리를 증성
메모리 증설로 대응할 수 없는 경우는 데이터 분산이나 캐시 서버 도입을 검토.
튜닝의 본래 의미는 병목현상이 발견되면 이를 제거하는
작업이다.
하드웨어나 소프트웨어가 지니고 있는 성능 이상의 성능을 내는 것은 아무리 노력해도 불가능하다.
본래 지닌 성능을 충분히 발휘할 수 있도록 문제가 될 만한 부분이 있다면 제거하는 것이다.
I/O 성능을 개선하기 위한 규명
원인을 알면 해당 원인에 대한 대응방법은 자명한 것이다.
이렇게 자명해진 대응 방법을 실천하는 것이 튜닝이다.
그 외
App의 부하분산
DB