리눅스 epoll 에서 epolloneshot, epollexclusive 플래그들이 어떻게 다른건가요?

개발만담 - 개발,업무,우리의 밥벌이와 관련된 만담 게시판.

리눅스 epoll 에서 epolloneshot, epollexclusive 플래그들이 어떻게 다른건가요?

retro

작성 : 2020-02-09 18:22:25 | 조회 : 2,070

둘다 Thundering-herd 문제를 피하려고 나온 플래그는 맡는거같은데

oneshot은 커널2.6.2때 이미 릴리즈되고 exclusive는 4.5때 또 나온거보니까 oneshot으로 해결못한문제가 뭐가 있었나보다 생각이되서 리눅스 문서를 읽어보고 있는데.. oneshot은 직접 epoll_ctl로 re-arm 해야하고 exclusive는 oneshot이랑 같으면서 epoll_ctl은 직접 호출 안해도 되는것만 보이네요.

제눈에는 이거 하나말고는 다른점을 못찾겠는데 제가 뭘 놓치고있는게 있는건가요?

아니면 syscall하나 줄이려고 4.5때 새로운 플래그가 나온건가요?

조상현

둘은 좀 많이 다르다고 보시면 됩니다.

oneshot은 한번 event를 받으면 리셋되버리기 때문에 순차적(?)으로 처리해야할 때 용의합니다.
대표적인 것이 tcp같은 stream i/o 경우인데요...
oneshot을 사용해 recv 이벤트를 받으면 받는 순간 event의 flag가 리셋되어버리므로 다시 event를 걸때까지는 recv를 받지 않겠죠.
따라서 recv의 처리도 중에 다시 recv가 들어와도 다른 쓰레드에서 recv가 처리될 것이라는 걱정없이 현재 처리중인 recv를 모두 처리한 후에 다시 EPOLLONESHOT | EPOLLIN으로 이벤트를 걸어서 순차적으로 recv를 받는 식으로 구현이 가능합니다.
근데 이걸... exclusive로 하게 되면 recv 이벤트를 받아 하나의 thread만 깨운다해도 처리하는 중 또 recv가 다른 쓰레드를 께워 버릴수 있으니까 순차처리에 문제가 생기겠죠.

exclusive가 유용한 대표적인 처리가 accept처리 같은 것인데...
accept처리는 소켓 별로 독립적으로 처리되니까 exclusive에 적합하죠.
accept 이벤트를 받아서 accept를 처리 중에 다른 accept 이벤트가 발생하면 다른 쓰레드를 깨워 accept를 받는 것이 유리하다는 것입니다.
이걸 oneshot으로 해버리면 한번에 하나씩 밖에 accept를 받아내지 못하는 거죠.

	2

2020-02-09
23:53:43

retro

To 조상현님

명확한 답변 정말 감사합니다. accept같이 전에 누가 어디서 몇바이트를 받았는지 전후사정을 확인을 안해도 되는 atomic한 이벤트들을 멀티스레드에서 더 효율적으로 처리하기위해 exclusive가 나온건가보군요. 염치없지만 질문몇개만 더 여쭤봐도 될까요?

이거는 예를들면서 질문을 해야될거같기때문에.. 2개의 스레드가 epoll_wait으로 대기 하고있다고 가정해볼게요.

1. listen중인 fd1에 외부로부터 connect시도했다고 커널에 통지됨.

2. epoll_wait중인 2개의 스레드중 thread 0이 일어나서 fd1에 accept하고 OnAccept같은 함수로 이벤트 핸들링중.

3. 그와중 fd1에 또 connect통지가 옴. epoll_wait하고있던 또다른 thread 1은 일어나서 위와같은 핸들링중.

4. listen중인 fd1에 connect 2개가 통지됨. 현재 epoll_wait 하고있는 스레드는 없음.

5. thread 0과 thread 1의 이벤트처리는 끝남. 다시 epoll_wait함수를 부름.

이렇게되면 둘중 하나의 스레드는 block하게되나요? 아니면 스레드 둘다 block하지않고 이벤트를 처리하러 일어나나요?

제가 위상황에서 어떻게될지 궁금한이유는 전자처럼 epoll_wait하고있는 스레드가 없을때 통지가된 이벤트들이 이벤트 하나로 합쳐지면 exclusive플래그를 사용한 로직도 accept처리할때 매번 accept에서 eagain을 뱉을때까지 확인해야될거같은데.. 후자라면 정말 좋겠지만 만약 전자처럼 된다면 밑에 상황을 exclusive로도 피할수 없는건가요?

1. listen중인 fd1에 외부로부터 connect시도했다고 커널에 통지됨.

2. epoll_wait 중인 2개의 스레드중 하나의 스레드 (thread 0)이 일어나서 처리중.

3. fd1에 또 connect 통지. 자고있던 thread 1은 일어남.

4. 그와중 이벤트처리가 끝난 thread 0은 eagain을 확인해야되기에 accept를 호출. 어라? 하나더있네? 또다시 처리.

5. 3에서 일어난 thread 1은 일을하기위해 accept를 호출해보지만 이미 thread 0이 자기할일을 뺏어감. 일어났는데 아무일도안하고 다시 자러감.

이런 디테일한부분은 영미권싸이트를 뒤져봐도 안나오면 제가 직접 코드짜서 실험해봐야되는데 리눅스를 wsl로 처음 접한지 얼마 안되서 실험환경을 만들기도 너무 벅차네요..(wsl 리눅스가 버전 4.5미만인건지 exclusive플래그를 지원 안하는거같고, IDE환경 설정하기도 힘들고..)

긴글 읽어주셔서 감사합니다.

2020-02-10
07:05:07

조상현

** 작성자(또는 관리자)에 의해 삭제된 댓글입니다 **

2020-02-10
12:49:12

조상현

음... 영미권 싸이트를 뒤져보면 금방 나올텐데...

어디까지 저 개인적인 경험이라 정확한 건지는 모르겠지만...
한마디로 EXCLUSIVE를 해도 loop돌면서 accept를 받아내야 합니다.

이건 상당히 복잡한 내용이라 직접해보고 경험하는 것이 가장 좋을겁니다.

EXCLUSIVE + Edge Trigging로 하나 EXCLUSIVE + Level Trigging으로 하나 동작이 좀 다르긴 하지만 두가지 다 accept 실패할 때까지 loop돌며 더 받을게 없을 때까지 accept해 줘야 할 겁니다.

EXCLUSIVE + Level Trigging을 걸었을 때에 접속이 한번 왔을 때 하나의 쓰레드만 깨어납니다.

하지만 모든 쓰레드가 바쁜 상황에서 두 개이상의 접속 시도가 오면 다음에는 뭉쳐서 한번만 쓰레드를 깨우게 됩니다. 이런 상황 때문에 loop를 돌면서 accept를 받도록 하죠.

EXCLUSIVE + Edge Trigging 을 했을 때에는 한번 쓰레드를 깨우면 backlog가 빌때까지 쓰레드를 다시 깨우지 않기 때문에 이 역시 돌면서 accept 받아내서 bakclog 비게해줘야 겠죠.

EXCLUSIVE는 Thundering-herd를 방지하기 위한 것이 한번의 signal로 한번의 accept를 하도록 만든 것은 아닌 듯합니다.
iocp는 한번의 signal로 한번의 accept가 처리되도록 되어 있습니다만 epoll은 그렇지 않죠.

여담이지만 epoll 이거 진짜 애초부터 설계가 잘못된게 아닌가 싶습니다.
linux에서 이거 외 별 선택지가 없어서 쓰긴 하지만 epoll로는 뭔가 딱딱 떨어지는 설계가 잘 안되더군요.
애초부터 iocp같이 제대로 비동기i/o로 설계된게 아니고 signal만 비동기로 받겠다는 컨셉으로 설계가 되다보니까... 날이갈수록 뭔가 안 맞는게 드러나고.. 그걸 보완하기 위해 뭐 level trigger, edge trigger, one shot, exclusive 이것저것 집어 넣다 보니까 이렇게 복잡하게 된게 아닌가 합니다.

	3

2020-02-10
13:02:55

retro

To 조상현님

아 epoll이 뭔가 직관적이지 않다 느껴지는게 저만그런게 아니였군요?

지금혼자 드는생각이.. Level-trigger로 하면 루프도는와중에 다른스레드 깨어났는데 할일은 없는 spurious wakeup이 일어날수있고, Edge-trigger로 하면 backlog 빌때까지 루프를돌아야되니 전체적인 분산은안되면 스레드 하나에만 일이 몰리는거아닌가? 그러면 계속 accept가 오는상황이면 backlog가 안비고 스레드 하나에서만 계속 accept루프 도는거아닌가? 그냥 AcceptEx GQCS보다 안좋은거 아닌가? 도대체 어떻게 이걸로 제대로된 서버를 만들라는거지?

대충 이러한데..

제가 그냥 winapi만 쓰다보니 여기에만 익숙해져있고 지금 제대로 확인도 못해서 epoll이 부정적으로 느껴지는줄알았는데 그게 아니였나보네요.

epoll이 iocp나 kqueue보다 좀 늦게나오지않았나요? 왜 과거의 모델들을 참고를 안하고 이상하계만들어놔서 아직까지 ET니 oneshot이니 exclusive니.. 플래그를 추가하며 덕지덕지 땜빵을 하는건지.. 라이센스 문제라도 있었나..

2020-02-10
13:52:15

엘레게스

IOCP와 맞먹을만한 것으로, kernel에서 I/O까지 수행해서 user에게 넘겨주는 API 설계 및 구현이 최근 커널부터 구현되고 있는 io_uring으로 볼 수 있을 것 같아요. 아직 충분히 안정적이라고 보기는 힘들고 아직 feature들 추가하는 단계인 것 같아서 실제 현업에 사용하기는 무리인 것 같지만요.

리눅스에서 왜 IOCP 같은 구현이 없었는지는 저도 잘은 모르겠지만, 단순히 아무도 설계, 구현을 하지 않았기 때문이 아닐까요? POSIX aio는 있었지만 disk I/O에서 한정적으로만 쓰이고...

2020-02-11
00:25:41

조상현

To retro....

네... exclusive로도 완벽한 효율을 추구하는 건 한계가 있습니다. 하지만 많이 개선되었다고 봅니다.
epoll은 비동기 i/o 전용 함수를 새로 만든 것이 아니라 기존 socket 함수들을 유지한 체 비동기 다중 쓰레드 처리를 지원하는 형식이라 좀 복잡한 면이 있고 어느 정도 한계는 있을 수 있습니다만 그렇다고 서버를 제대로 못만들 정도라고 하기는 좀...

분명 기존에 select로 fork나 polling을 하는 방식에 비해서는 압도적으로 성능이 향상되었으니까요.

2020-02-11
05:25:28

imays

exclusive 플래그 없음 : 한 소켓을 여러 epoll이 물고 있을 때, avail i/o가 발생하면 여러 epoll 모두가 signal을 받는다.

exclusive 플래그 있음: 모두가 받는게 아니고 여러 epoll 중 한 놈만 signal을 받는다.

즉슨, 한 소켓을 여러 epoll에다가 물리실 것 아니면 쓸 일이 없는 플래그입니다.

2020-02-11
11:08:34

imays

싱글스레드에서 다수의 소켓을 처리할 때는 epoll이나 iocp나 그게 그거입니다.

그런데 멀티스레드(스레드풀)에서 다수의 소켓을 처리할 때는 균형있게 처리가 배분되면서, 한 소켓에 대한 중첩 처리는 일어나지 않게 해야 하는데, 이걸 잘 해내는건 iocp뿐이며, epoll은 이것을 하지 못합니다.

epoll이 그렇게 못하는 이유는 iocp를 만든 쪽에서 관련 기술을 특허로 선점 보유하고 있기 때문인걸로 압니다.

여담: 게임서버프로그래밍교과서(배현직 저)에서 iocp와 epoll을 비교해가면서 설명하고 있습니다. ㅎㅎㅎㅎ

여담2: 프라우드넷의 경우, 리눅스에서도 다수의 소켓을 처리하는 스레드풀 구조로 만들어져 있습니다. 하지만 epoll의 한계 때문에 iocp만큼 완벽한 균형 처리 배분을 하지는 않습니다. 그래도 게임서버의 특징(한 클라는 통신량이 적은데 이런 클라가 겁나 많이 붙는다) 상황에서는 문제없이 잘 작동합니다. ㅎㅎㅎㅎ

2020-02-11
11:17:30

imays

그렇다고 리눅스로 하시던걸 굳이 윈도로 바꾸지는 마세요. 평소 익숙한걸로 하시면 됩니다.

상기 제가 언급한

이 점을 제외하고 epoll은 iocp보다 훨씬 러닝타임도 짧고 api도 일관성있게 만들어져 있고 iocp보다 실수에 둔감해서, 인간 실수와 관련된 서버 안정성 쪽에서는 iocp보다 안정적입니다. 즉 상기 임팩트한 성능 케이스를 제외하고 iocp보다 epoll이 훨씬 예쁩니다.

2020-02-11
11:33:17