net.core.somaxconn 매개 변수에 대한 인수에 들어갔습니다. 기본 128을 변경해도 아무런 차이가 없다고 들었습니다.
나는 이것이 충분한 증거라고 생각했다.
"백 로그 인수가 / proc / sys / net / core / somaxconn의 값보다 큰 경우 해당 값으로 자동으로 잘립니다" http://linux.die.net/man/2/listen
하지만 그렇지 않습니다.
누구나 Gbit 네트워크에 앉아있는 두 대의 컴퓨터로 이것을 증명하는 방법을 알고 있습니까? 가장 좋은 것은 MySQL, LVS, apache2 (2.2), memcached에 대한 것입니다.
답변:
net.core.somaxconn더 높은 값으로 설정 하는 것은 새로운 연결 속도가 너무 높거나 높아서 128 개 (BSD의 경우 : 128 backlog+ 64 half-open) 아직 수락되지 않은 연결이 정상으로 간주 되는 고부하 서버에서만 필요합니다 . 또는 "정상"정의를 응용 프로그램 자체에 위임해야 할 때.
일부 관리자는 높은 net.core.somaxconn서비스를 사용하여 서비스 문제를 숨기므로 사용자의 관점에서 볼 때 연결 중단 / 시간 초과 ( net.ipv4.tcp_abort_on_overflowLinux에서 제어) 대신 대기 시간이 급증하는 것처럼 보입니다 .
listen(2)manual net.core.somaxconnsays-더 작은 것을 자유롭게 선택할 수있는 응용 프로그램의 경우에만 경계를 설정합니다 (일반적으로 응용 프로그램 구성에서 설정). 일부 앱은 listen(fd, -1)백 로그를 시스템이 허용하는 최대 값으로 설정한다는 의미 만 사용 합니다.
진짜 원인 중 낮은 처리 속도 (예를 들어 단일 스레드 차단 서버) 또는 작업자 스레드 / 프로세스의 수가 부족한 (예를 들어 멀티 - 프로세스 / 소프트웨어와 같은 차단 나사산 apache/를 tomcat)
추신. 때때로 사용자가 기다리게하는 것보다 빠르게 실패하고로드 밸런서가 작업을 재 시도하도록하는 것이 바람직합니다.이를 위해 net.core.somaxconn모든 값 을 설정 하고 애플리케이션 백 로그를 예를 들어 1로 10설정 net.ipv4.tcp_abort_on_overflow합니다.
PPS. 이전 버전의 Linux 커널에는 somaxcon16 개의 하위 비트로 값을 자르는 불쾌한 버그가 있습니다 (즉 uint16_t, 값을 캐스트 )하여 해당 값을 더 많이 올리면 65535위험 할 수 있습니다. 자세한 내용은 http://patchwork.ozlabs.org/patch/255460/을 참조하십시오.
Linux의 모든 백 로그 내부에 대한 자세한 내용을 보려면 Linux에서 TCP 백 로그의 작동 방식 을 읽으십시오 .