허용되는 평균 부하

금요일에 새로운 Linux / Exim / Spamassassin 메일 서버를 배포했습니다 (관리자가없는 긴 주말 전날에 항상 배포하는 것이 좋습니다). 평균 15 분 동안 부하는 1.3 정도였습니다.

기기가 응답하고 메일이 적절한 시간에 배달됩니다. 이것이 수용 가능하다고 가정 할 수 있습니까?

일정량의 하중이 어떻게 수용 가능한 것으로 간주됩니까? 어떤 측정 항목이 사용됩니까?

기본 원칙 : 시스템이 반응 형이고 적시에 작동하면 괜찮습니다.

두 개 미만의 하중은별로 걱정하지 않습니다. 네트워크 또는 드라이브에 많은 대기열 문제가 있음을 나타내는 지표이지만 시스템이 4 ~ 5 대를 맞았지만 여전히 잘 작동합니다 (I / O 문제는 시스템이 매우 반응이 빠르더라도 높은 부하를 유발할 수 있음).

메일 대기열 길이를 주기적으로 확인하고 전달할 수없는 문제 및 해당 문제의 로그를 확인하십시오. 배달 큐가 상대적으로 낮은 상태라면 괜찮습니다.

디스크 평균 및 네트워크 I / O 정보를 얻을 수 있지만 배달 문제가 표시되지 않으면 (15 분 전에 메시지를 보냈지 만 아직 도착하지 않았습니다!) 콘솔을 통해 시스템에서 작업 할 수 있습니다 ( 또는 ssh) 대기 시간이 많지 않으면 괜찮을 것입니다.

로드 평균은 기다릴 필요없이 필요할 때 모든 작업을 실행할 수 있도록 커널에 필요한 프로세서 수를 알려주는 값입니다.
2 개 이상의 CPU / 코어가있는 경우 문제 없습니다. 코어가 1 개인 CPU가 1 개뿐이라면 앱을 실행하려는 시간과 커널이 실행하는 시간 사이에 '너무 많은'시간이 있다는 의미입니다. 너무 긴 시간 동안 너무 높은 값에 도달 할 때까지로드> "CPU / 코어 수"는 메일 시스템에 문제가되지 않습니다.
물론 그것들은 규칙과 가치가 없으며 짧은 시간 안에 메일을받는 동안 괜찮습니다. 그러나로드가 '긴'기간 (~ 1 시간) 동안 2 * CPU / 코어 수보다 너무 많을 경우 서버를 면밀히 살펴보아야합니다.
다시 한 번 메일 서버의 경우 큰 문제는 아니지만 서버가 약간 오버로드되었음을 의미합니다.

튜닝 관련 질문과 함께 항상 그렇습니다 / 아니오 답변은 없습니다.

그러나 멀티 코어 CPU 구성을 사용하는 경우 1.3의로드는 높지 않습니다. 로드 수가 코어 수와 같으면 모든 코어에 항상 프로세스를 실행할 준비가되어 있습니다.

궁극적으로, 메시지가 적시에 전달되면 성능이 좋습니다 :-)

top

거의 실시간으로 기본 측정 항목을 제공합니다.

가지고있는 CPU의 수보다 적은로드 평균은 CPU가 아무 것도하지 않고 앉아 있다는 것을 의미합니다. 같음은 모두 현재 작동하고 있음을 의미합니다. 더 크다는 것은 실행 중일 수 있지만 대기중인 프로세스가 있다는 의미입니다.

voip 서버 또는 memcache와 같은 슈퍼 시간에 민감한 항목의 경우 평균 avg 이하의 부하를 원합니다. 전자 메일과 같은 가끔 백업을 수행 할 수있는 비동기식의 경우 코어 수를 4 배 쉽게 실행할 수 있습니다.

기억해야 할 가장 큰주의 사항은 디스크 나 네트워크 i / o를 기다리고 있지만 실행 가능한 프로세스는 여전히로드 평균에 표시된다는 것입니다. 따라서 아파치 서버 스푼 피드 jpg를 56k 사용자에게 제공하는 경우 기가비트 LAN을 통해 프록시 /로드 밸런서에 대한 PHP / 어떤 스크립트 응답을 다시 실행하는 것보다 훨씬 높은로드 평균을 실행할 수 있습니다. 귀하의 경우 첨부 파일을 전송하는 데 시간이 오래 걸리는 느린 메일 서버에 대한 smtp 연결은 런 큐에서 1 프로세스를 표시하지만 20 번 중단되어 문제없이 gmail에 빠른 한 줄짜리 이메일을 보낼 수 있습니다.

푸시는 밀려오고,로드 평균은 DOW와 같습니다. 실제로 어떤 식 으로든 "경제"를 측정하지는 않습니다. 사람들은 단순히 이야기하기 쉬운 매우 느슨하게 상관 된 측정법으로 사용합니다. 배달 큐 깊이 및 초당 메시지와 같이 실제로 관심있는 모니터링 메트릭에 중점을 둡니다.

코어가 몇 개입니까? 고양이 / proc / cpuinfo | 그렙 프로세서 | 화장실 -l

(캐비티 : 하이퍼 스레딩은 더 많은 코어처럼 보이지만 그렇지 않습니다)

로드 레벨이 프로세서 수보다 적은 경우 일반적으로 정상입니다.

또한 상단을보고 '1'을 누르면 각 CPU의 개별로드를 볼 수 있습니다.

예, 꽤 수용 가능하며 일반적으로 메일 필터로 예상되는 것입니다.

우리의 설정은 약간 다릅니다. SpamAssassin을위한 별도의 서버가 있으며 POP 서버는 ClamAV를 실행하여 바이러스를 검사합니다. POP 서버는 일반적으로 2의 서버로드에서 실행되지만 때때로 최대 10 이상으로 급증합니다. 반면에 SpamAssassin 서버는 CPU 사용량을 두 배로 늘리고 15 이상으로 급등한 상태에서 약 5 미만으로 실행되는 Openprotect.com 필터를 설치할 때까지 약 2 회 실행했습니다. 메일 지연으로 인해 메일 큐가 증가하고 (메일 수신에 qmail 사용) CPU 사용량 / 메모리를 절약 할 여유가 여전히 있습니다.

우연히도, 나는 서버 모니터링을 위해 Munin 을 강력히 추천 합니다. 과거 데이터를 시각적으로 시연하고 어떤 리소스를 절약해야 하는지를 보여줍니다. Top (1)으로 실시간 모니터링은별로 도움이되지 않습니다. :)

어쨌든 긴 주말 전에 금요일에 배포하는 것이 주말 내내 일하기에 좋은 방법입니다. 특히 메일 서버와 같은 중요한 시스템의 경우.

메모리 소비는 어떻습니까? 안정적인가요?

하중이 표준을 벗어난 것으로 보이지는 않습니다. 메일 서버가 응답하고 메일이 통과하는 경우 잘못된 전자 메일이 스팸 메일을 통과하는 경우 메모리 소비를 넘어서는 실패를 측정하는 유일한 방법이라고 할 수 있습니다.

오늘 당신의 첫 번째 실제 시험이 될 것입니다. 나는 오늘 그것을 가볍게 모니터링 할 것입니다. 문제가 발생하면 지금이 시간입니다.