선택/폴링과 비교의 주의사항Twisted의 epoll 반응기

Question

내가 읽고 경험한 모든 것(Tornado 기반 앱)은 ePoll이 Select 및 Poll 기반 네트워킹, 특히 Twisted를 자연스럽게 대체한다고 믿게 했습니다.더 나은 기술이나 방법론이 대가를 치르지 않는 경우는 거의 없습니다.

epoll과 대안 간의 수십 가지 비교를 읽어 보면 epoll이 속도와 확장성 측면에서 확실히 챔피언이라는 것을 알 수 있습니다. 특히 선형 방식으로 확장된다는 점은 환상적입니다.즉, 프로세서와 메모리 활용은 어떻습니까? epoll이 여전히 챔피언입니까?

Answer 1

매우 적은 수의 소켓(물론 하드웨어에 따라 다르지만 대략 10개 이하에 대해 이야기하고 있음)의 경우 Select는 메모리 사용량과 런타임 속도에서 epoll을 능가할 수 있습니다.물론 이렇게 적은 수의 소켓의 경우 두 메커니즘 모두 너무 빠르기 때문에 대부분의 경우 이 차이에 대해 실제로 신경 쓰지 않습니다.

하지만 한 가지 설명이 있습니다.select와 epoll 모두 선형적으로 확장됩니다.그러나 큰 차이점은 사용자 공간을 향한 API가 서로 다른 사항을 기반으로 하는 복잡성을 가지고 있다는 것입니다.비용 select 호출은 전달한 가장 높은 번호의 파일 설명자 값과 대략적으로 일치합니다.단일 fd 100을 선택하면 단일 fd 50을 선택하는 것보다 대략 두 배의 비용이 듭니다.가장 높은 값 아래에 더 많은 fd를 추가하는 것은 무료가 아니므로 실제로는 이보다 조금 더 복잡하지만 이는 대부분의 구현에 대한 좋은 첫 번째 근사치입니다.

epoll의 비용은 실제로 이벤트가 있는 파일 설명자 수에 더 가깝습니다.200개의 파일 설명자를 모니터링하고 있지만 그 중 100개에만 이벤트가 있는 경우 (대략적으로) 해당 100개의 활성 파일 설명자에 대해서만 비용을 지불하게 됩니다.이것은 epoll이 select에 비해 주요 이점 중 하나를 제공하는 경향이 있는 부분입니다.대부분 유휴 상태인 클라이언트가 1,000개 있는 경우 select를 사용하면 해당 클라이언트 1,000개 모두에 대해 여전히 비용을 지불하게 됩니다.그러나 epoll을 사용하면 단지 몇 개만 있는 것과 같습니다. 특정 시간에 활성화된 항목에 대해서만 비용을 지불하면 됩니다.

이 모든 것은 epoll이 대부분의 작업 부하에서 CPU 사용량을 줄여준다는 것을 의미합니다.메모리 사용량에 관한 한 약간의 문제가 있습니다. select 필요한 모든 정보를 매우 컴팩트한 방식(파일 설명자당 1비트)으로 표현합니다.그리고 사용할 수 있는 파일 설명자 수에 대한 FD_SETSIZE(일반적으로 1024) 제한 select 이는 함께 사용할 수 있는 세 가지 fd 세트 각각에 대해 128바이트 이상을 소비하지 않는다는 것을 의미합니다. select (읽기, 쓰기, 예외).최대 384바이트에 비하면 epoll은 일종의 돼지입니다.각 파일 설명자는 다중 바이트 구조로 표시됩니다.그러나 절대적인 측면에서는 여전히 많은 메모리를 사용하지 않습니다.수십 킬로바이트(파일 설명자 1000개당 대략 20,000개 정도)로 엄청난 수의 파일 설명자를 표현할 수 있습니다.그리고 해당 바이트 중 384바이트를 모두 소비해야 한다는 사실도 고려할 수 있습니다. select 하나의 파일 설명자만 모니터링하려고 하는데 해당 값이 1024인 경우 epoll을 사용하면 20바이트만 소비하게 됩니다.하지만 이 숫자는 모두 매우 작기 때문에 큰 차이는 없습니다.

또한 이미 알고 계시겠지만 epoll의 또 다른 이점은 FD_SETSIZE 파일 설명자에만 국한되지 않는다는 것입니다.이를 사용하여 보유한 만큼의 파일 설명자를 모니터링할 수 있습니다.그리고 파일 설명자가 하나만 있고 그 값이 FD_SETSIZE보다 큰 경우 epoll은 그것과도 작동하지만 select 하지 않습니다.

무작위로, 나는 또한 최근에 약간의 단점을 발견했습니다. epoll 비교하자면 select 또는 poll.이 세 가지 API 중 어느 것도 일반 파일(즉, 파일 시스템의 파일)을 지원하지 않지만, select 그리고 poll 항상 읽고 쓸 수 있는 설명자를 보고하는 것으로 이러한 지원 부족을 나타냅니다.이로 인해 다음을 사용하는 프로그램인 의미 있는 종류의 비차단 파일 시스템 I/O에 적합하지 않게 됩니다. select 또는 poll 파일 시스템에서 파일 설명자를 만나면 최소한 계속 작동합니다(또는 실패하더라도 select 또는 poll), 아마도 최고의 성능은 아닐 수도 있습니다.

반면에, epoll 오류로 인해 빠르게 실패합니다(EPERM, 분명히) 그러한 파일 설명자를 모니터링하라는 요청을 받았을 때.엄밀히 말하면 이는 틀린 말은 아니다.단지 명시적인 방식으로 지원 부족을 알리는 것뿐입니다.일반적으로 나는 명시적인 실패 조건에 박수를 보내지만 이것은 문서화되지 않았으며(내가 알 수 있는 한) 잠재적으로 성능이 저하된 상태로 작동하는 것이 아니라 완전히 손상된 응용 프로그램을 초래합니다.

실제로 이런 일이 발생하는 것을 본 유일한 곳은 stdio와 상호 작용할 때였습니다.사용자는 표준 파일에서/로 표준 입력 또는 표준 출력을 리디렉션할 수 있습니다.이전에는 stdin과 stdout이 epoll에서 지원되는 파이프였으나 일반 파일이 되고 epoll이 크게 실패하여 애플리케이션이 중단됩니다.

Answer 2

우리 회사의 테스트에서 epoll()에 대한 한 가지 문제가 발생하여 select와 비교하여 단일 비용이 발생했습니다.

시간 초과가 있는 네트워크에서 읽으려고 할 때 epoll_fd(FD_SET 대신)를 생성하고 epoll_fd에 fd를 추가하는 것은 FD_SET(간단한 malloc)을 생성하는 것보다 훨씬 비쌉니다.

이전 답변에 따르면 프로세스의 FD 수가 많아지면 select() 비용이 높아지지만 테스트에서는 fd 값이 10,000대라도 select가 여전히 승자였습니다.이는 스레드가 대기 중인 fd가 하나만 있고 차단 스레드 모델을 사용할 때 네트워크 읽기 및 네트워크 쓰기가 시간 초과되지 않는다는 사실을 극복하려는 경우입니다.물론 블로킹 스레드 모델은 비블로킹 리액터 시스템에 비해 성능이 낮지만 특정 레거시 코드 베이스와 통합하기 위해 필요한 경우가 있습니다.

이런 종류의 사용 사례는 고성능 애플리케이션에서는 드물다. 리액터 모델이 매번 새로운 epoll_fd를 생성할 필요가 없기 때문이다.epoll_fd가 수명이 긴 모델의 경우(모든 고성능 서버 설계에 확실히 선호되는 경우) epoll이 모든 면에서 확실한 승자입니다.