Linux 호스트의 크기를 적절하게 조정하려면 백로그를 이해하는 것이 중요합니다. procs_running(특히 코어 수로 나눈 경우)는 프로세스 백로그를 나타내는 좋은 지표이지만 스레드 백로그에 대한 통찰력을 제공하지는 않습니다. 로드 평균 측면에서는 모든 것이 원활해 보이지만 일시 중지 기반 스레드는 CPU에 큰 부담을 줄 수 있습니다. 예를 들어, 단일 프로세스가 소켓을 수신하고 여러 스레드를 생성하여 여러 소켓 연결을 처리하는 경우 이러한 상황이 발생할 수 있습니다. 각 스레드는 CPU에 로드를 가합니다. 이 경우에는 프로세스가 하나만 실행 중이므로 로드 평균과 procs_running은 낮지만 CPU는 100%로 고정되어 클라이언트 워크로드에 대한 대기 시간이 높습니다.
그러한 스레드 큐의 크기에 대한 통찰력을 얻을 수 있는 방법이 있습니까? CPU가 실행되기를 기다리는 스레드가 있습니까?
답변1
procs_running스레드와 동등한 것은 procs_running그 자체입니다. 그것은 포함한다반환 값nr_running,실행 중인 스레드 수입니다..
(일반적으로 커널에 관한 한 스레드는 프로세스입니다.)
답변2
좀 더듬어 본 후에는 기본적으로 내 질문에 답할 수 있습니다.
-Lps프로세스의 모든 스레드에 대한 옵션이 포함되어 있습니다 . 내 호스트에서 이것을 관찰한 결과, 클라이언트가 네트워크를 통해 내 서비스에 연결하기 시작할 때 procs_running은 결코 4(코어당 1)를 초과하지 않지만 프로세스와 관련된 휴면 스레드가 있다는 것을 알았습니다. 숫자는 78에서 140으로 증가하기 시작하고 모든 클라이언트가 요청을 완료할 때까지 78로 돌아가지 않습니다. 이 작업은 약 1시간 정도 소요되며, 이 시간 동안 모든 코어의 활용도는 100%로 유지됩니다. 로드 평균은 4를 초과하지 않습니다.
따라서 -L실제로 이 특별한 경우, 네트워크 요청을 처리하는 프로세스가 있는 경우 해당 옵션은 좋은 백로그 지표입니다. 이 경우 procs_running(로드 평균과 직접적인 관련이 없음)은 백로그의 크기를 나타냅니다. 이는 하나의 상위 프로세스만이 연결된 클라이언트 수에 따라 새 스레드를 분기하고 procs_running상위 프로세스의 대기열 크기만 반영하기 때문입니다.
내가 이해하지 못하는 유일한 것은 스레드가 상태로 표시된 이유입니다 Sleep. CPU 시간을 기다리고 있기 때문에 실행 가능해야 한다고 생각합니다. 이 질문에 대한 답을 아는 사람이 있으면 알려주시기 바랍니다.
질문에서 언급했듯이 백로그를 측정할 수 있는 것이 중요한 이유는 예를 들어 인스턴스 크기 조정입니다. 단순히 전류 활용도를 측정하는 것만으로는 충분하지 않습니다.
편집: 이는 만족스럽지 않습니다. 일반적으로 각 스레드가 백로그(procs_running)에 1을 기여할 것으로 예상하지만 여기서는 그렇지 않습니다. 내가 끌어낼 수 있는 유일한 결론은 자체 스레드에서 sleeps()를 실행하는 것과 같이 애플리케이션이 내부적으로 자체 작업을 수행하고 있다는 것입니다. OS가 설정된 소켓 수 외에 보류 중인 백로그를 알 수 있는 방법이 없습니다.
그런데 문제의 애플리케이션은 puppetserver입니다.