접미사 성능

우분투에서 postfix를 실행하여 매일 많은 양의 메일 (~ 백만 메시지)을 보냅니다. CPU 및 메모리로드 측면에서로드는 매우 높지만 많지는 않습니다. 비슷한 상황에 처한 사람이 있고 병목 현상을 제거하는 방법을 알고 있습니까?

이 서버의 모든 메일이 아웃 바운드입니다.

병목 현상이 디스크라고 가정해야합니다.

iostat는 다음과 같습니다.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

이 숫자가 단일 디스크에서 기대하는 성능과 일치합니까?

sdb는 접미사 전용입니다.

들어오는-> 활성-> 지연에서 큐 셔플 링이라고 생각합니다.

질문에서 자세한 내용 :

서버 : 쿼드 코어 제온 CPU E5405 @ 2.00GH, 4GB 램

로드 평균 : 464.88, 489.11, 483.91, 4 코어. 그러나 메모리 사용률과 CPU는 최소입니다

16-32 사이의 접미사 인스턴스

약간 미친 소리로 들릴 수도 있지만 다음을 수행해야합니다.

1. 로깅을 필요한 최소한으로 줄이십시오. syslog 만 mail.err 이상을 로그하게하십시오.
2. RAM을 더 추가하십시오. 예, Postfix는 필요하지 않지만 추가 RAM은 커널에 대한 추가 페이지 캐시를 의미합니다.
3. / dev / sdb에 어떤 파일 시스템이 있는지 언급하지 않았지만 (일부 사항도 중요합니다) 확실히로 전환 noatime하여 부하를 조금 줄이십시오.
4. / var / spool / postfix의 크기를 확인하십시오. 커플 공연 아래라면 램 디스크로 옮기는 것을 고려하십시오.

"/ var / spool / postfix"에 RAM 디스크 사용을 제안한 것에 동의하지 않아야합니다. 이는 전체 메일 대기열이 RAM에 저장됨을 의미합니다. 서버가 고장 나거나 전원이 꺼지면 대기열의 메시지가 영구적으로 사라집니다. 메시지가 이미 배달을 위해 성공적으로 수락 되었기 때문에 이것은 클라이언트 / 사용자 관점에서 실제로 나쁜 것입니다. 더 나쁜 것은 서버가 다시 시작될 때 대기열이 비었기 때문에 서버가 전자 메일을 반송했거나 배달 할 수 없다는 알림을 보내지 않는 것입니다.

대신, 나는 당신이 감당할 수있는만큼 빠른 디스크를 추가하고 싶습니다; 주어진 정보에 얼마나 많은 정보가 필요한지 알 수 없습니다. 위의 "iostat"출력에서 ~ 120 IOPS ~ 'sdb'(r / s 및 w / s의 합)를 수행하는 것처럼 보입니다. 단일 15k RPM SCSI 또는 FC 디스크가 150 IOPS를 처리 할 것으로 합리적으로 추정 할 수 있습니다. 5 개의 15k RPM SCSI 디스크와 알맞은 RAID 컨트롤러로 시작하겠습니다. 1 개의 핫 스페어가있는 4 개의 드라이브에서 RAID-10으로 설정하십시오. 이것이 귀하의 문제를 완전히 해결할 것이라고 확신하지는 않지만 확실히 악화 시키지는 않습니다.

일부 프로파일 러 (gprof?)에서 postfix를 실행하거나 로그를 확인하십시오. Postfix는 보류 위치를 알려줄 수있는 많은 타이밍 정보를 기록합니다. 보아야 할 일반적인 장소는 다음과 같습니다.

1. 디스크 성능. 대기열에 RAID-10이 필요할 수 있습니다.
2. 메시지에 대한 모든 종류의 네트워크 IO. DNS 블랙리스트? SAV?
3. 설치 한 Milter 및 기타 필터
4. 네트워크 또는 프로세스 (ldap, sql)를 통한 인증 및 UID 조회
5. 프록시를 사용하지 않는 경우 : 느린지도 (위와 같이)

처리량이 일정하다고 가정하면 하루에 백만 개의 메시지가 초당 약 11입니다. Postfix 자체는 엔트리 레벨 서버 하드웨어보다 최소한 10 배 이상을 처리 할 수 ​​있어야합니다. 그래서 나는 당신이 postfix를 실행하는 것 이상, 또는 매우 고르지 않게 분산 된 처리량 피크를 가지고 있다고 생각합니다.

당신의 상황은 확실히 I / O 바운드 서버처럼 보입니다. MTA를 사용하면 메일을 잃지 않도록 작은 쓰기 작업을 많이 수행해야합니다.

/var/spool/postfix와 에서 모두 I / O를 조정하는 데 시간이 걸립니다 /var/log. 사용량이 많은 postfix 서버에 대한 가장 좋은 방법은 두 스핀들을 서로 다른 스핀들로 분리하고 비동기 로깅을 활성화하는 것입니다. Linux에서 메일 로그의 로그 파일 이름 앞에 대시를 붙입니다.

mail.info                              -/var/log/mail.log

또는 유사합니다.

amavisd-new를 사용하는 경우 작업 영역이 tmpfs 파일 시스템에 있는지 확인하십시오. 우리는 보통 그것을 입습니다 /tmp/vscan/. amavisd-new는 다운 스트림 (포스트 필터) 홉이 메시지를 수락 할 때까지 데이터 끝 응답을 반환하지 않기 때문에 안전합니다.

어떤 사람들 noatime은 postfix 스풀에 대한 마운트 옵션을 권장 합니다. postfix가 파일 시스템 의미에 의존하는 방식으로 인해 이는 잠재적으로 현명하지 않습니다. 예를 들어 http://archives.neohapsis.com/archives/postfix/2006-01/1916.html을 참조하십시오 .

디스크 하위 시스템을 적어도 문제의 일부로 봐야 할 것 같습니다. postfix가 / var 주위에서 파일을 섞는 방식으로 인해 파일 시스템 수준에서 성능을 향상시킬 수 없는지 확인하기 위해 "t3 파일 시스템 조정 (최소한 noatime 및 쓰기 저장)"에 대한 인터넷 검색을 제안합니다.

고객 대상 전자 메일에 대해 DNS와 아웃 바운드 SMTP를 두 배로 처리하고 매일 I / O 바인드와 거의 같은 곳에서 매일 250k 메시지 (2k-10k / 시간)를 실행하는 두 개의 서버 클러스터가 있습니다.

스토리지 성능 병목처럼 보입니다.

99.88의 iowait는 시스템이 스토리지를 기다리는 데 많은 시간을 소비하고 있음을 나타냅니다.

Bill Weiss에 동의합니다. 대기열에 대한 raid10 설정을 조사해야합니다.

또는 시작

vmstat 1

moshen이 제안한 "iostat 1"도 좋습니다

통계에서 분명히 더 빠른 디스크 하위 시스템이 좋을 것입니다. 6-8 15k rpm 디스크의 raid-10은 캐시에 몇 기가의 메모리가 내장되어있을 수 있습니다.

noatime, nodiratime 옵션으로 스풀 디렉토리를 마운트하십시오. 많은 작은 파일을 처리하기 위해 파일 시스템 조정 또는 변경을 고려하십시오.

브라이언

더 빠른 디스크를 얻거나 습격 솔루션으로 옮기는 것이 좋습니다. 어떤 종류의 서버입니까?

제임스

스팸 + 바이러스 필터링을 위해 amavis를 실행중인 경우 동시 amavis 프로세스 수를 늘려야합니다. 설정에 따라 postfix master.cf의 smtp-amavis 프로세스 수와 amavis.conf의 관련 설정을 모두 늘려야 할 수 있습니다.

상자에 몇 개의 코어가 있으며 실제 하중은 얼마입니까? 실제 메시지 전송 속도는 얼마입니까?

대부분의 첫 생각은 디스크이므로 확인하십시오.

그러나 높은 인터럽트로드 (잘못된 카드) 일 수 있으므로 네트워크 사용률이 원인 일 수 있으므로 확인하십시오. 같은 메일 박스에 빠른 캐싱 DNS 서버 ( "바인딩되지 않은"부분 임)를 가지고 있으면 아무리 작은 메일 서버라도 대기 시간과 네트워크로드를 줄이는 데 도움이됩니다.

630 읽기 및 초당 1042 쓰기를 수행하면 시스템에서 메모리를 늘리고 (OS 및 램 드라이브를 더 잘 처리하기 위해) postfix 폴더를 램 디스크로 만드는 것이 좋습니다.

자체 디스크가 아닌 경우 메일 로그를 자체 파티션에 배치하는 것이 좋습니다.

이것은 IO 문제가 아니며, 후위 구성 문제입니다. 한 번에 너무 많은 일을하도록 요구하고 병목 현상을 일으킬 수 있습니다. postfix 성능 조정 추가 정보를 확인 하거나 main.cf를 게시하여 도움을 받으십시오.

닷지 디스크가있는 것 같습니다. 서버는 초당 72 읽기 요청 및 42 쓰기 / 초만 수행합니다. Seagate 7200 RPM 데스크탑 HDD는 초당 100 개 이상의 임의 읽기 / 쓰기 요청을 수행하고 여전히 대처할 수 있습니다.

스풀에 스풀을 장착하고 부하가 좋아지는 지 확인하십시오.

그러나 디스크에 더 많은 돈을 뿌리기 전에 다음을 수행하십시오.

1. qshape active, qshape deferred 및 qshape 수신을 실행하고 각 명령의 총계를 알려주십시오.

   지연된 대기열에있는 메일 수가 비정상적으로 많으면 스팸 발송자가 메일 서버를 사용하여 스팸을 릴레이 할 수 있습니다 (예 : 존재하지 않는 도메인으로 전자 메일을 보내면 접미사가 계속해서 다시 시도됩니다).

2. 메일 서버가 블랙리스트에 없는지 확인하십시오 ( http://www.mxtoolbox.com/blacklists.aspx )

3. DNS 응답 시간을 확인하고 로컬 DNS 캐시를 실행하십시오.

   메일 서버는 DNS를 상당히 많이 사용합니다. 마 dig somedomain.com mx 실행 위에 몇 가지 다른 호스트. 일반적으로 응답 시간은 100-400ms 미만이어야합니다. 더 높은 응답을 얻으면 DNS가 제대로 작동하지 않을 수 있습니다. 다른 DNS를 사용해보십시오 (Google의 8.8.8.8 또는 OpenDNS : 208.67.222.222 시도)

4. 네트워크를 확인하십시오. (예 : ifconfig) 오류 패킷 수를 확인하십시오. 링크가 포화 또는 모양인지 확인하십시오. 메일 로그에 시간 초과 작업이 많지 않은지 확인하십시오. tcpdump를 수행하고 패킷이 유실되거나 재전송되지 않도록하십시오.

5. 콘솔이 반응 형인지 알려줄 수 있습니까 (예 : 명령을 입력 할 때 시스템이 얼마나 빨리 피드백을 제공합니까)?

   일반적으로 네트워크 문제 (예 : DNS)로 인해 부하가 급증하지만 시스템은 여전히 ​​반응합니다.