load average를 파악하는 uptime과 커널 메시지를 출력하는 dmesg

이 내용은 인프런의 "리눅스 성능 분석 시작하기"의 일부임을 미리 밝힙니다.

 

저 같은 경우에는 docker에 ubuntu 환경을 띄워 환경을 구성했습니다.

 

만약 따라하실 분의 경우 docker run할 때 `--privileged` 옵션을 주어야 dmesg 내용을 확인할 수 있습니다.

uptime

Linux에서 uptime 명령어로 load average를 파악할 수 있다. load average란 서버가 받고 있는 부하 평균을 의미한다.

1분 평균 0.16, 5분 평균 0.03, 15분 평균 0.01을 의미한다.

예를 들어 1이라면 그 시간동안 작업이 할당된 프로세스 수를 말한다. 즉, 이 값이 CPU 수보다 높다면 CPU는 자기가 가능한 정도 이상의 일을 하고 있는 것이고 그만큼의 지연이 발생하게 된다.

 

load average는 상대적인 수치이다. CPU 개수당 부하를 의미하는 것이 아니기 때문에 현재 시스템의 CPU 수를 넘는지를 우선 확인하는 것이 중요하다.

 

 

CPU 수는 lscpu -e 명령어로 확인할 수 있다.

 

load average를 확인했으면 이 프로세스가 어떤 작업을 하고 있는지를 확인해야 한다. 여기서 신경써야 할 건 R / D 상태의 프로세스이다.

R 상태란 CPU 위주의 작업을 하는 프로세스를 의미한다. 시스템에 이 상태의 프로세스가 많다면 CPU 수를 늘리거나 쓰레드 개수를 줄여서 대응할 수 있다.

 

D 상태란 I/O 위주의 작업을 의미한다. IOPS가 높은 디바이스로 변경하거나 처리량을 줄여 대응할 수 있다.

 

procs 컬럼의 r, b를 확인하면 된다

프로세스의 상태는 vmstat 명령어로 확인할 수 있다.

dmesg

dmesg는 커널에서 발생하는 다양한 메시지를 출력한다. 이 명령어는 주로 OOME나 SYN Flooding 상황을 확인하기 위해 사용한다.

 

OOME란 Out Of Memory-Error의 약자이며, 프로세스가 메모리를 너무 많이 가지고 있을 때 발생한다. (주로 힙영역)

 

OOME 발생시 Linux는 OOM Killer라는 게 동작해서 oom_score라는 자신만의 기준으로 다른 프로세스들을 종료시켜 메모리를 더 할당받을 수 있게 만든다.

 

dmesg -T | grep -i oom 명령어로 OOM Killer가 발생했는지 확인할 수 있다.

 

SYN Flooding이란 공격자가 SYN 패킷만 보내 소켓을 고갈시키는 공격이다. 간단히 말해 3-way handshake 요청을 엄청나게 많이 보내는 것이다.

 

https://brunch.co.kr/@alden/5

 

만약 SYN 요청이 너무 많이 일어나서 SYN 요청들을 담는 일종의 버퍼인 SYN Backlog가 가득찬다면, 이후의 SYN 패킷들을 버리게 되어 연결할 수 없게 된다.

 

이 경우 Linux에서는 SYN Cookie 라는 걸 만든다. SYN Cookie란 SYN 패킷의 정보를 바탕으로 만든 쿠키로, SYN + ACK(3-way handshake에서 SYN에 대한 응답은 SYN + ACK니까)의 시퀀스 번호로 만들어 응답한다.

 

SYN Cookie가 동작하면 SYN Backlog에 패킷이 더이상 안 쌓이므로 자원 고갈 현상이 발생하지 않지만, 정상적인 TCP Option을 무시한 것이기 때문에 Windows Sliding 등 성능 향상을 위한 옵션이 동작하지 않는다.

• TCP Option : TCP 연결 관리 기능을 확장하는 역할을 한다. MSS(Maximum Segment Size)를 정하거나 window size를 정하는 등을 할 수 있다.
• Window size : Client측 TCP의 수신 가능한 버퍼 사이즈. SYN Flag와 함께 전송된다
• Sliding Window : Client에서 한 번에 처리할 수 있는 패킷 수를 Server에 알려 ACK라는 대답을 일일이 기다리지 않아도 되도록 만드는 기법. Stop and Wait 방식과 비교

따라서 SYN Cookie는 성능상으로 불이익이 생기기 때문에 SYN Flooding이 감지되었을 때만 동작한다.

 

dmesg -TL | grep -i "syn flooding" 명령어로 SYN Flooding이 발생했는지 확인할 수 있다.

 

요즘은 클라우드 환경이 워낙 좋아서 ALB(AWS) 혹은 WAF단에서 확인이 가능하다

느낀 점

처음에는 어차피 요즘 로그들 회사에서 다 관리해주고, 지표 같은 것들도 모두 읽어와서 중앙 로그 서버에서 관리해 주기 때문에 서버에 직접 들어가서 확인할 일은 거의 없겠다는 생각이 들었었는데, 막상 수업들 듣다 보니 생각이 조금 바뀌었다.

 

애초에 서버에 들어가서 이런 로그들을 읽는다는 것은 커널 단에서의 메시지를 읽는 것에 조금 더 초점을 맞춘 행위 같다. (또한 내가 알기로 Cloud Watch를 통해 AWS 환경에서 1분 내의 로그를 읽으면 신뢰할 수 없는 걸로 안다)

 

따라서 분석하고 통계를 맞추고 그런 용도 보다는 문제가 닥쳤을 때 그에 신속하게 대응하기 위해 이러한 명령어들을 알아두면 도움이 될 것 같다는 생각이 들었다.

 

강의는 "인프런의 리눅스 성능 분석 시작하기"인데, 핵심만 간추려서 잘 설명해주기 때문에 강력 추천한다.

- https://www.inflearn.com/course/%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%84%B1%EB%8A%A5-%EB%B6%84%EC%84%9D-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0#reviews

리눅스 성능 분석 시작하기 - 인프런 | 강의

 

강의에서 추천해준 레퍼런스도 하나 남긴다.

https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55