접미사 성능

접미사 성능

우분투에서 postfix를 실행하여 하루에 많은 메일(~1백만 메시지)을 보냅니다. 로드는 매우 높지만 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는 postfix 전용입니다.

수신->활성->지연 순으로 대기열을 섞는 것 같습니다.

질문에 대한 자세한 내용:

서버: 쿼드 코어 Xeon(R) CPU E5405 @ 2.00GH, 4GB RAM

평균 로드: 464.88, 489.11, 483.91, 4코어. 하지만 메모리 사용률과 CPU는 최소화됩니다.

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

답변1

조금 이상하게 들릴 수도 있지만 다음을 수행해야 합니다.

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

답변2

나는 "/var/spool/postfix"에 RAM 디스크를 사용하자는 제안에 동의하지 않습니다. 이는 전체 메일 대기열이 RAM에 저장된다는 의미입니다. 서버가 충돌하거나 전원이 꺼지면 대기열의 메시지가 영원히 사라집니다. 메시지 전달이 이미 성공적으로 승인되었기 때문에 이는 클라이언트/사용자 관점에서 볼 때 매우 좋지 않습니다. 더 나쁜 것은 서버가 다시 돌아올 때 대기열이 비어 있기 때문에 이메일이 반송되었거나 배달될 수 없다는 알림을 서버에서 보내지 않는다는 것입니다.

대신에 저는 여러분이 감당할 수 있는 만큼 빠른 디스크를 추가하겠습니다. 주어진 정보로는 얼마나 많은 양이 필요할지 실제로 예측할 수 없습니다. 위의 "iostat" 출력에서 ​​'sdb'(r/s와 w/s의 합)에 ~ 120 IOPS를 수행하는 것처럼 보입니다. 단일 15k RPM SCSI 또는 FC 디스크가 150 IOPS를 처리할 것으로 합리적으로 추정할 수 있습니다. 15,000RPM SCSI 디스크 5개와 괜찮은 RAID 컨트롤러로 시작하겠습니다. 핫 스페어 1개가 포함된 드라이브 4개에 걸쳐 RAID-10으로 설정합니다. 이것이 귀하의 문제를 완전히 해결할 수 있을지는 확신할 수 없지만, 문제가 더 악화되지는 않을 것입니다.

답변3

일부 프로파일러(gprof?)에서 postfix를 실행하거나 로그를 살펴보세요. Postfix는 정지 위치를 알려주는 많은 타이밍 정보를 기록합니다. 흔히 볼 수 있는 장소는 다음과 같습니다.

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

답변4

적어도 문제의 일부로 디스크 하위 시스템을 살펴봐야 할 것 같습니다. postfix가 /var 주위에서 파일을 섞는 방식으로 인해 "ext3 파일 시스템 조정"(적어도 noatime 및 writeback 설정)에 대해 인터넷 검색을 통해 파일 시스템 수준에서 성능을 향상할 수 없는지 확인하는 것이 좋습니다.

나는 고객이 보내는 이메일에 대해 DNS와 아웃바운드 SMTP를 이중으로 수행하고 그런 종류의 I/O 바인딩 근처에 전혀 없이 매일 250,000개의 메시지(시간당 2,000~10,000개)를 실행하는 두 개의 서버 클러스터를 가지고 있습니다.

관련 정보