Day 1: strace로 시스템 콜 분석하기

목표

애플리케이션이 느리거나 장애가 발생했을 때, strace로 시스템 콜을 분석하여 원인을 찾을 수 있어야 한다.

 

시스템 콜이란?

애플리케이션이 파일을 읽거나, 네트워크 통신을 하려면 운영체제(커널)에게 하드웨어에 접근해달라는 요청을 해야하고, 이 요청을 시스템 콜(System Call) 이라고 한다.

DevOps 엔지니어가 시스템 콜을 알아야 하는 이유는?

AI는 해당 상황을 장애 상황으로 보고 제시를 해주었으나, 작은 파일 150만 개를 개별적으로 열고 닫는다는 진단이 해당 로그를 보고 어떻게 나온 것인지 궁금하였음

- AI의 답변 및 답을 찾아가는 개인적인 사고 방식

1. 애플리케이션 로직이 돌고 있지 않은데 CPU를 100% 사용하고 있기 때문에 OS에서의 사용이 클 것이라고 예상함

2. strace -c 명령어로 OS의 시스템 콜의 현황을 살폈더니 open/read/close 가 같은 수로 반복되었음

3. 유추할 수 있는 것은 파일을 열고 -> 읽은 뒤 -> 닫는다의 패턴이라고 유추할 수 있음

4. 이것이 작은 파일이라고 유추할 수 있는 단서라고 생각되지 않았음

5. read는 어플리케이션이 지정한 버퍼 크기만큼만 데이터를 가져오기 때문에 큰 파일은 EOF에 도달할 때까지 read를 반복 호출한다.

6. 그렇기 때문에 용량이 큰 파일은 open 1 / read 수백 ~ 수천 / close 1 이라는 패턴을 가진다.

7. 하여, open/read/close가 같은 수로 반복된다면 버퍼 크기보다 작은 양의 read를 했다는 것이기에, 용량이 작은 파일이라고 유추가 가능하다.

8. 시스템 콜은 모드 전환 -> 레지스터 저장 및 복원 -> 권한 검사 -> 커널 코드 실행 -> 커널 모드 전환 이라는 고정 비용이 발생한다.

9. 그렇기 때문에 버퍼링 또는 배치처리로 시스템 콜 횟수를 감소 시킬 수 있음.

10. 이 때, 버퍼링과 배치의 차이가 궁금해졌음.

11. 버퍼링은 데이터를 모아 한 번에 요청하기 때문에 고정비용인 open/close/read의 시스템 콜의 수는 동일함 (read 횟수만 감소)

12. 배치는 요청을 한 번에 모아 요청하기 때문에 고정비용인 open/close/read의 시스템 콜 수 자체를 줄일 수 있음

13. 만약 지금의 현상처럼 open/close/read 가 1:1:1이라면 버퍼링을 적용한다고 해도 어차피 3번의 시스템 콜 수는 동일해짐

14. read가 cpu 시간을 많이 차지하는 것은 커널과 유저 공간 간 메모리 복사 비용이 누적된 결과임. 특히 작은 파일을 다량 처리할 때 이런 현상이 보통 발생함.

15. 이 경우에는, 배치 작업을 통한 고정 시스템 콜 수를 줄여 병목을 해결할 수 있음.

자주 보게 될 시스템 콜

실습 1

아무 활동을 하지 않는 프로세스에 연결하였더니, 아무런 시스템 콜이 올라오지 않았음

학습 핵심 명령어

학습을 마무리하며

애플리케이션이 느리거나 장애가 발생했을 때, 원인을 찾지 못하는 경우에는 strace 명령어를 통해 시스템 콜을 분석하고 원인을 찾을 수 있을 것이라는 판단근거의 확장이 되었다.