CPU 사용량 비율과 평균 부하율의 차이, 언제 걱정해야 할까요?

여기에서 여러 답변을 검색했지만 이 시나리오와 관련된 답변을 찾을 수 없습니다. 답변을 찾았다고 생각되면 알려주세요.

이해를 돕기 위해 여기에 숫자를 추가합니다.

캐시 서버 역할을 하는 내부 서면 이벤트 기반 분산 비동기 네트워크 서비스를 실행하는 데 전용으로 사용되는 256GB RAM을 갖춘 96코어 베어메탈 Linux 서버가 있습니다. 데몬은 32개의 작업자 스레드로 실행됩니다. 가져오기 및 캐싱이라는 주요 작업 외에도 서버는 상태 확인을 위해 다른 멤버 폴링, Unix 소켓에 메트릭 쓰기 등과 같은 여러 추가 개별 스레드에서 다양한 관련 작업을 수행합니다. 이 값을 늘리면 캐시 잠금 경합이 증가하므로 작업자 스레드 값은 't'입니다. 이 서버는 메트릭 일괄 쓰기를 시도하므로 디스크 활동이 많지 않으며 Unix 소켓이 실패하면 이를 무시하고 메모리를 해제합니다.

이 인스턴스는 9노드 클러스터의 일부이며 이 노드에 대한 통계는 클러스터의 나머지 인스턴스를 나타냅니다.

최근 인바운드 트래픽이 급증하면서 프로세스의 CPU 사용률이 크게 증가한 것을 볼 수 있지만 로드 평균은 여전히 ​​1 미만입니다.

아래 통계를 확인해 보세요.

:~$ nice top
top - 19:51:55 up 95 days,  7:27,  1 user,  load average: 0.33, 0.28, 0.32

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
587486 cacher   20   0  107.4g  93.0g  76912 S  17.2  37.0   5038:13 cacher

때로는 %CPU80%까지 올라가기도 하지만 로드 평균이 매우 낮고 결코 1.5를 초과하지 않습니다. 이는 대부분 캐시 누락이 있고 캐시가 업스트림에서 캐시를 가져와야 할 때 발생하므로 대부분 설정된 네트워크 활동입니다. 내가 이해한 바로는 서비스가 런타임에 수행하는 계산 집약적인 작업은 캐시할 항목을 적절한 분산 버킷에 저장해야 할 때 캐시할 항목의 해시를 계산해야 한다는 것입니다. 이 서비스의 매개변수에는 시스템 제한이 설정되어 있지 않으며 프로세스에 대해 커널 oomkiller를 비활성화하도록 조정되었습니다. 단, 상한선에 가깝지는 않습니다. 바인딩된 systemd 소켓은 더 많은 tx 및 rx 버퍼를 수용하도록 조정되었습니다.

• 96코어 서버의 평균 부하가 1보다 작은데 %CPU32개의 스레드를 사용하는 서비스의 부하가 계속 20~80% 사이를 오가는 이유는 무엇입니까?
• 96코어 서버에서 %CPU안전한 작동을 위한 안전한 값으로 간주되는 것은 무엇입니까? 사용되는 스레드 수와 관련이 있습니까? 스레드 수가 증가하면 이론적으로 더 높은 CPU 사용량이 허용됩니까?

감사해요.