dongho-jung
commented
3 years ago 이 이슈에서 다루고 있는 시나리오는 크게 cpu bound job이냐 io bound job이냐로 구분한거 같아요.
monitor, troubleshoot, suggest 각 단계에서 두가지 경우로 나눠 정리해주셨는데 각각이 개별적인 시나리오로 들어가도 괜찮을것 같습니다.
요약의 요약인지라 이것만으로는 완결성 있는 시나리오가 나오긴 어려울것 같고 이후 시나리오들을 리서치하거나 검증할때 참고하기 좋을것 같아요!
저도 처음에 I/O 부하가 높은데 페이지캐시의 존재를 몰라서 삽질을 했었거든요. 캐시의 존재를 항상 유의하고 시나리오 검증을 하면 도움이 많이 되겠네요.
=================================================================================== 출처
대용량 데이터 서비스를 운영하기 위해서는 서버 부하의 원인을 파악하고, 이를 해결할 수 있어야한다.
성능, 부하란 무엇인가
병목을 규명하기 위한 작업
1) Load Average 확인
2) CPU, I/O 중 병목 원인 조사
Load Average가 높은 경우, 다음으로 CPU와 I/O 어느 쪽에 원인이 있는지를 조사해야한다.
참고 : sar, vmstat으로 시간 경과에 따라 CPU 사용률이나 I/O 대기율이 추이를 확인할 수 있다.
=================================================================================== monitor
CPU 부하가 높은 경우 사용자의 프로그램의 처리가 병목인지, 시스템의 프로그램이 원인인지 확인
I/O 부하가 높은 경우 일반적으로 프로그램으로부터 입출력이 많아서 부하가 높거나, 스왑이 발생해서 디스크 액세스가 발생하고 있는 상황인 경우가 많다.
Identify and analysis
top, sar과 같은 명령어 이용
sar, vmstat을 이용해 문제를 파악
suggest
ps 명령어로 볼 수 있는 프로세스 상태나 CPU 사용시간 등을 보면서 원인이 되고 있는 프로세스를 찾는다. 프로세스를 찾은 후, 보다 상세하게 조사할 경우는 strace 명령어로 추적하거나 oprofile로 프로파일링해서 병목지점을 좁혀나간다.
(ex1) 스왑이 발생하는 경우
(ex2) 스왑이 발생하지 않고, 디스크로의 입출력이 빈번하게 발생하고 있는 상황 캐시에 필요한 메모리가 부족한 경우로 생각해 볼 수 있다. 해당 서버가 저장하고 있는 데이터 용량과 증설 가능한 메모리량을 비교해서 다음과 같이 나눠서 검토한다.
물론, 프로그램을 개선해서 I/O를 빈도를 줄이는 것도 검토가능하다.