CPU 당 유니콘 프로세스 당 최적 수

Unicorn에서 Ruby on Rails 웹 앱을 실행하고 있습니다. 우리의 응용 프로그램은 CPU 제한이 아닙니다 (코어가 12 인 듀얼 Xeon E5645 시스템을 가지고 있으며 피크로드 평균 값은 약 6입니다). 처음에는 40 명의 유니콘 작업자로 시작했지만 시간이 지남에 따라 애플리케이션 메모리 공간이 증가했습니다. 따라서 작업자 프로세스 수를 줄여야합니다. 나는 표준 (CPU 코어 수 + 1) 공식이 Unicorn에도 적용된다고 생각했지만 동료는 CPU 당 더 많은 Unicorn 인스턴스를 예약 하고이 링크를 제공해야한다고 설득하려고했습니다 . 그러나 유휴 유니콘 프로세스에 왜 그렇게 많은 메모리를 사용해야하는지 정확히 모르겠습니다.

내 질문은 : CPU 코어 당 하나 이상의 유니콘 인스턴스를 갖는 이유는 무엇입니까? 유니콘의 건축 적 특징 때문입니까? 바쁜 Unicorn 프로세스가 새로운 연결을 수락 할 수 없다는 것을 알고 있습니다 (UNIX 도메인 소켓을 사용하여 Unicorn 인스턴스 BTW와 통신 중임).이 문제를 해결하기 위해 백 로그가 정확하게 도입되었다고 생각했습니다. CPU 규칙마다이 2 ~ 8 개의 유니콘 인스턴스를 극복 할 수 있습니까?

좋아, 나는 마침내 답을 찾았다. 최적의 유니콘 워커 수는 CPU 코어 수에 직접 연결되어 있지 않으며로드 및 내부 앱 구조 / 응답성에 따라 다릅니다. 기본적으로 샘플링 프로파일 러를 사용하여 근로자의 상태를 파악하고 근로자를 70 % 유휴 상태로 유지하고 30 %는 실제 작업을 수행합니다. 따라서 샘플의 70 %는 "프론트 엔드 서버에서 요청을 받기 위해 select () 호출을 기다리고 있습니다". 우리 연구에 따르면 작업자의 유효 상태는 3 가지뿐입니다. 샘플의 0-30 %가 유휴 상태이고 샘플의 30-50 %가 유휴 상태이며 샘플의 50-70 %가 유휴 상태입니다 (예 : 더 많은 유휴 상태의 샘플을 얻을 수 있지만 응용 프로그램 응답 성이 크게 변경되지 않기 때문에 실제 포인트는 아닙니다. 우리는 0-30 % 상황을 "적색 구역"으로 간주하고 30-50 % 상황을 "황색 지역"으로 간주합니다.

CPU 바운드 작업의 경우 N + 1이 맞습니다.

반면, 유니콘은 스레드를 사용하지 않으므로 모든 IO op. 프로세스를 차단하고 다른 프로세스가 HTTP 헤더를 시작하고 구문 분석하고 문자열을 연결하며 사용자에게 서비스를 제공해야하는 모든 CPU 집약적 작업을 수행합니다 (요청 대기 시간을 줄이기 위해 더 일찍 수행).

그리고 코어보다 더 많은 스레드 / 프로세스를 원할 수 있습니다. 다음 상황을 상상해보십시오. req. A는 요구보다 10 배나 더 걸립니다. B, 당신은 여러 개의 동시 A 요청을 가지고 있으며 빠른 B 요청은 A-req가 완료되기를 기다리는 중입니다. 따라서 많은 수의 요청을 예측할 수 있으면이 수를 다른 지침으로 사용하여 시스템을 조정할 수 있습니다.