[TroubleShooting] epollWait란 무엇일까? (EpollWait CPU High)

최근 L 사이트에서 Thread Runnable 중, epollWait 상태의 스레드들이 CPU를 과점유하여 CPU High로 인한 서비스 불능 현상이 발생했다.

사실 이러한 경우,

top -H로 Thread 별 CPU 점유율을 확인하면 epollWait 상태의 스레드가 CPU를 과점유하고 있다고 쉽게 판단할 수 있지만, 해당 사이트 환경에서는 top -H가 없는 관계로 확인할 수가 없었다.

 

그래서 epollWait를 검색하던 중, 해당 원인으로 인한 CPU High 이슈가 상당히 많이 존재하고 있음을 확인했다.

1) https://forum.flashphoner.com/threads/100-cpu-usage-from-netty-epoll.11390/

2) https://github.com/netty/netty/issues/327

3) https://www.reddit.com/r/admincraft/comments/5wtago/why_is_epollwait_using_so_much_cpu_time/

....

 

그래서 궁극적으로 epollWait이란 놈이 무엇인지? 간단하게만 적어보고자 한다..

epoll에 대해서 이해하기 위해서는 먼저 파일디스크립터(FD)를 알아야 하는데, 여기서는 간단한 개념 정도만 익혀보자.

 

※ 파일디스크립터란 (FD, File Descriptor)
유닉스 OS에서 네트워크 소켓과 같은 파일이나 기타 입/출력 리소스에 액세스하는데 사용되는 추상 표현이다.
즉, 시스템으로부터 할당받은 파일이나 소켓을 대표하는 정수라 할 수있다.

(소켓 통신을 위해 소켓을 생성할 때 시스템은 FD 값을 지정해준다.)

그렇기 때문에 소켓 통신시에도 이러한 FD 값을 이용한다고 볼 수 있는데,

Epoll은 클라이언트의 파일 디스크립터를 모아놓고 동시에 이들을 관찰할 수 있는 I/O 통지 모델이다.
그리하여, 운영체제에게 관찰대상에 대한 정보를 딱 한번만 알려주고 관찰대상에 대한 변경(Events)이 있을 때 변경사항만 알려주는 방식이다.

간단한 Client-Server 통신의 예로 들면, Client와 Server간의 소켓 통신 시 절차를 보면 아래와 같다.

1. Client(로컬) 소켓은 Connect()를 수행하여 Listen 중인 원격에 SYN을 보내고 SYN_SENT 상태가 된다.
이때 SYN_SENT는 epoll_wait으로 원격으로부터 다시 SYN 메시지가 올 때까지 기다린다.

2. SYN을 받은 Server(원격)의 소켓은 SYN_RECV 상태가 되고 다시 Client(로컬)에 SYN을 보낸다.

3. SYN을 받은 로컬 소켓은 ESTABLISHED 상태가 된다.

이때 만약, Client와 Server 사이의 방화벽으로 막혀 있어서 Client -> Server로 정상적으로 ping이 되지 않을 경우, Client는 Server를 호출하면서 소켓을 열고 epollWait 상태로 CPU High가 지속적으로 발생할 수 있다.

 

※ 참고 블로그

- https://code4human.tistory.com/123

파일 디스크립터(File Descriptor)란?