![애플리케이션 호스트에서 실행할 프로세스 수를 결정할 때 무엇을 고려해야 합니까? [폐쇄]](https://linux55.com/image/92014/%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%ED%98%B8%EC%8A%A4%ED%8A%B8%EC%97%90%EC%84%9C%20%EC%8B%A4%ED%96%89%ED%95%A0%20%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%20%EC%88%98%EB%A5%BC%20%EA%B2%B0%EC%A0%95%ED%95%A0%20%EB%95%8C%20%EB%AC%B4%EC%97%87%EC%9D%84%20%EA%B3%A0%EB%A0%A4%ED%95%B4%EC%95%BC%20%ED%95%A9%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
저는 운영 부문에 근무하므로 일부 서비스 배포에 대한 주요 의사 결정자입니다. 제가 작업하는 분산 애플리케이션에는 다양한 유형의 "서비스"가 포함되어 있으며 그 중 일부는 다른 것보다 더 까다롭습니다. 혼동을 일으키고 싶지 않기 때문에 "서비스"라고 말합니다. 이는 동일한 C++ 실행 파일의 여러 인스턴스이며 시작할 서비스 유형을 exe에 알리는 매개 변수가 다릅니다.
전통적으로 과거에 서비스를 배포한 방식은 비율이었습니다. 1:1
방법 service-counts:cores
은 cores
다음과 같습니다. 아니요 hyper-threaded cores
.
예!
4
물리적 CPU가 있고 각각 코어가 있는 호스트 입니다4
./proc/cpuinfo
이 호스트 에서는 가지고 있는 것으로 표시됩니다. 여기서부터는32 processors
이것이 제가 의미하는 바가 아닙니다 .cores
나는4cpus x 4cores == 16 cores
총 수에 대해 이야기하고 있습니다.
서비스가 동시에 동일한 장면에서 병렬로 작동하므로 우리 시스템은 다중 스레드가 아닙니다. 배포되지만 그렇지 않습니다.스레드. 우리 서비스는 스레드 전체에서 서로 많은 메모리를 공유하지 않습니다(대부분 데이터베이스 정보라고 생각합니다). 알아두셔야 할 중요한 정보일 수 있습니다.
내 질문은 우리 소프트웨어가 기술적으로스레드스레드 계산을 활용하려고 시도하지 않기 때문에(주로분산화service:core
취급 하중), 비율 에 신경을 써야 합니까 ? 나는 이것이 다른 서비스에서 차지할 수 있는 사용되지 않은 주기를 낭비하는 것처럼 느낍니다.
예!
- 호스트에는 16개의 코어가 있고 16개의 프로세스를 실행합니다.
Load average: 2.94 2.96 3.01
- 서비스 로드는
40%
각각 약 입니다(이 상자에는 동일한 유형의 서비스 16개).
로드 평균은 상대적으로 낮지만 1:1
메모리 버스 경합의 복잡성(즉, 동일한 코어의 스레드는 동일한 메모리 버스에 액세스하기 위해 경쟁함)에 대해 잘 알지 못합니다. 더 많은 프로세스를 호스팅하는 것은 시스템의 코어 수 Load average
와는 거리가 멀습니다.16
질문!
service:core
주로 비율을 무시하고 대신 서비스 로드와 박스 로드에 주로 초점을 맞춘 새로운 전략을 KPI로 제안할 때 무엇을 고려해야 합니까? 이러한 유형의 응용 프로그램에 대해 고려해야 할 더 자세한 세부 사항이 있습니까?
답변1
로드 평균 이외의 다른 요인으로는 메모리 사용량, 컨텍스트 전환, 디스크 또는 네트워크 I/O(또는 서비스가 포트를 얼마나 불필요하게 사용하는지에 따라 임시 포트 압력)가 있으며, 특히 단일 호스트에 더 많은 서비스가 번들로 제공되는 경우에는 더욱 그렇습니다. 또한 100% 로드된 시스템은 일일, 주간 또는 월간 크론 작업이 시작될 때 재난에 빠질 수 있습니다(재미있는 사실: OOM 킬러는 일반적으로 sshd
크론 일일 작업으로 인해 오전 4시에 종료됩니다). 따라서 여유 공간을 남겨 두는 것이 편리할 수 있습니다. 용량.
어떤 유형의 서비스 모니터링이 있습니까? 서비스에 대한 대기 시간 및 처리량 지표가 있는 경우 다양한 구성을 테스트하고 해당 결과를 현재 기준 사례와 비교할 수 있습니다. (상황이 악화되면 병목 현상이 발생한 위치를 알 수 있습니다...)
그리고 하나의 시스템에 더 많은 데이터가 쌓인다면, 그 박스에 불이 붙으면 복구 상황은 현재 설정에 비해 얼마나 나쁠까요?