리눅스에서 폴링과 선택의 차이점은 무엇입니까?

Linux에서 폴링과 선택의 차이점은 다음과 같습니다. 단일 선택 프로세스로 열 수 있는 최대 연결 수는 "FD_SETSIZE" 매크로로 정의되고 크기는 32개의 정수입니다. 반면 폴링은 연결 목록 저장소를 사용하므로 최대 연결 수에는 제한이 없습니다.

이 튜토리얼의 운영 환경: linux7.3 시스템, Dell G3 컴퓨터.

Linux에서 폴링과 선택의 차이점은 무엇입니까?

각 프로세스에서 사용하는 선택에는 최대 연결 수에 대한 제한이 있으며 이는 FD_SETSIZE만 가능하지만 폴링에는 그러한 제한이 없습니다(연결된 목록 저장소 사용).

epoll과 select는 모두 다중화 I/O를 위한 솔루션을 제공할 수 있습니다. 모두 현재 Linux 커널에서 지원될 수 있으며, 그 중 epoll은 Linux에 고유한 반면 select는 POSIX에서 규정하고 일반 운영 체제에서 구현해야 합니다.

select:

select는 기본적으로 설정이나 확인을 통해 저장됩니다. fd 플래그 비트의 구조는 다음 처리 단계에 사용됩니다. 단점은 다음과 같습니다.

1 단일 프로세스로 모니터링할 수 있는 fd 수는 제한되어 있습니다. 즉, 수신 포트의 크기가 제한되어 있습니다.

일반적으로 이 숫자는 시스템 메모리와 밀접한 관련이 있습니다. 구체적인 숫자는 cat /proc/sys/fs/file-max에서 확인할 수 있습니다. 32비트 시스템의 기본값은 1024입니다. 64비트 시스템의 기본값은 2048입니다.

2. 소켓을 스캔할 때 선형 스캔, 즉 폴링 방법이 사용되므로 덜 효율적입니다.

소켓이 많은 경우 select() 스케줄링을 완료하려면 FD_SETSIZE 소켓을 트래버스할 때마다 전달되어야 합니다. 어떤 소켓이 활성 상태인지에 관계없이 모두 트래버스됩니다. 이로 인해 CPU 시간이 많이 낭비됩니다. 소켓에 대한 콜백 함수를 등록하고 관련 작업이 활성화될 때 자동으로 완료할 수 있으면 폴링을 피할 수 있습니다. 이것이 epoll과 kqueue가 수행하는 작업입니다.

3. 많은 양의 fd를 저장하려면 데이터 구조를 유지해야 하는데, 이는 사용자 공간과 커널 공간 간에 구조를 전송할 때 높은 복사 오버헤드를 발생시킵니다.

poll:

poll은 본질적으로 동일합니다. 사용자가 전달한 배열을 커널 공간에 복사한 후 각 fd에 해당하는 장치 상태를 쿼리하고 장치가 준비되면 장치 대기 대기열에 항목이 추가되고 순회가 계속됩니다. . 모든 fd를 순회한 후에도 준비된 장치가 발견되지 않으면 장치가 준비되거나 이니셔티브가 시간 초과될 때까지 현재 프로세스가 활성화된 후 fd를 다시 순회합니다. 이 프로세스는 불필요한 순회를 많이 거쳤습니다.

Linked List 기반으로 저장되기 때문에 최대 연결 수에 제한이 없지만 단점도 있습니다.

1. User 모드와 커널 주소 공간에 관계없이 그러한 복제가 의미가 있습니까?​​​​​​​​​​

2. 폴링의 또 다른 특징은 "수평 트리거링"입니다. fd가 보고되었지만 처리되지 않은 경우 다음 폴링 시 fd가 다시 보고됩니다.

epoll:

epoll에는 EPOLLLT와 EPOLLET의 두 가지 트리거 모드가 있습니다. LT는 기본 모드이고 ET는 "고속" 모드입니다. LT 모드에서는 fd에 읽을 데이터가 있는 한 epoll_wait는 사용자 프로그램에 작동을 상기시키기 위해 매번 이벤트를 반환합니다. ET(edge ​​​trigger) 모드에서는 다음 데이터가 있을 때까지 한 번만 메시지를 표시합니다. fd에 여전히 읽을 수 있는 데이터가 있는지 여부에 관계없이 유입되기 전에 더 이상 프롬프트가 표시되지 않습니다. 따라서 ET 모드에서는 fd를 읽을 때 모든 버퍼를 읽어야 합니다. 즉, read의 반환 값이 요청된 값보다 작거나 EAGAIN 오류가 발생할 때까지 읽어야 합니다. 또 다른 기능은 epoll이 "이벤트" 준비 알림 방법을 사용하여 epoll_ctl을 통해 fd를 등록한다는 것입니다. fd가 준비되면 커널은 콜백과 유사한 콜백 메커니즘을 사용하여 fd를 활성화하고 epoll_wait는 알림을 받을 수 있습니다.

epoll에 EPOLLET 트리거 모드가 있는 이유는 무엇입니까?

EPOLLLT 모드를 채택하면 시스템에 읽거나 쓸 필요가 없는 준비된 파일 설명자가 많으면 epoll_wait가 호출될 때마다 반환되므로 작업 효율성이 크게 떨어집니다. 관심 있는 준비된 파일 설명자를 검색하는 핸들러입니다. EPOLLET의 엣지 트리거 모드를 사용하는 경우 모니터링되는 파일 설명자에서 읽기 및 쓰기 가능한 이벤트가 발생하면 epoll_wait()는 핸들러에 읽고 쓰기를 알립니다. 이번에 모든 데이터를 읽고 쓰지 않으면(예: 읽기-쓰기 버퍼가 너무 작은 경우) 다음에 epoll_wait()를 호출할 때 알림을 보내지 않습니다. 파일 설명자는 두 번째 읽기 및 쓰기 가능 이벤트가 발생할 때까지 알림을 받지 않습니다! ! ! 이 모드는 수평 트리거보다 효율적이며 사용자가 신경 쓰지 않는 많은 수의 준비된 파일 설명자로 시스템이 넘치지 않습니다. epoll의 장점:

1 최대 동시 연결 수에는 제한이 없습니다. , 그리고 열 수 있는 FD의 상한은 1024보다 훨씬 큽니다(1G 메모리는 약 100,000개의 포트를 모니터링할 수 있습니다).

Select, poll, epoll 차이점 요약:

1 프로세스에서 열 수 있는 최대 연결 수를 지원합니다.

select

단일에서 열 수 있는 최대 연결 수입니다. 프로세스는 FD_SETSIZE 매크로에 의해 정의되며 크기는 32개의 정수 크기입니다(32비트 시스템에서 크기는 3232이고 마찬가지로 64비트 시스템에서 FD_SETSIZE는 3264입니다). 이를 수정하고 커널을 다시 컴파일하면 성능이 영향을 받을 수 있으므로 추가 테스트가 필요합니다.

poll

poll은 기본적으로 select와 동일하지만 연결리스트 기반으로 저장되기 때문에 최대 연결 수에 제한은 없습니다

epoll

최대 연결 수에는 제한이 없습니다. 1G 메모리를 탑재한 머신은 약 100,000개의 커넥션을 열 수 있고, 2G 메모리를 탑재한 머신은 약 200,000개의 커넥션을 열 수 있습니다

2. FD

select의 급격한 증가로 인한 IO 효율성 문제.

선형 순회라고 할 때마다 연결이 처리되기 때문에 FD가 증가하면 순회 속도가 느려지는 "선형 감소 성능 문제"가 발생합니다.

poll

위와 동일

epoll

epoll 커널의 구현은 각 fd의 콜백 함수를 기반으로 하기 때문에 활성 소켓만 적극적으로 콜백을 호출하므로 활성 소켓이 적을 때는 epoll을 사용하지 않습니다. 이전 두 가지의 선형 성능 저하 문제가 있지만 모든 소켓이 활성화되면 성능 문제가 발생할 수 있습니다.

3. 메시지 전달 방법

select

커널이 사용자 공간에 메시지를 전달해야 하는데, 이를 위해서는 커널 복사 작업이 필요합니다

poll

위와 동일

epoll

epoll은 서로 간에 메모리를 공유하여 이루어집니다. 커널과 사용자 공간.

요약:

요약하자면, select, poll, epoll을 선택할 때 구체적인 사용 사례와 이 세 가지 방법의 특성을 고려해야 합니다.

1. 표면적으로는 epoll이 가장 좋은 성능을 보이지만 연결 수가 적고 연결이 매우 활발한 경우에는 결국 epoll의 알림 메커니즘에는 많은 기능이 필요합니다. 콜백.

2. Select는 매번 폴링을 해야 하기 때문에 비효율적입니다. 그러나 비효율성은 상대적이며 상황에 따라 좋은 디자인을 통해 개선될 수도 있습니다

추천 학습: Linux 비디오 튜토리얼

위 내용은 리눅스에서 폴링과 선택의 차이점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!