Wydajność Postfix

Uruchamianie Postfixa na Ubuntu, wysyłanie dużo poczty (~ 1 milion wiadomości) dziennie. obciążenia są wyjątkowo wysokie, ale niewiele w zakresie obciążenia procesora i pamięci. Ktoś w podobnej sytuacji i wie, jak usunąć wąskie gardło?

Cała poczta na tym serwerze jest wychodząca.

Musiałbym założyć, że wąskim gardłem jest dysk.

Tylko aktualizacja, oto jak wygląda 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

Czy te liczby są zgodne z wydajnością, jakiej można oczekiwać od pojedynczego dysku?

sdb jest dedykowany postfiksowi.

Myślę, że jest to przetasowanie kolejki, od przychodzących -> aktywnych -> odroczonych

Więcej szczegółów z pytań:

Serwer: czterordzeniowy procesor Xeon (E) E5405 @ 2.00GH z 4 GB pamięci RAM

Średnia obciążeń: 464,88, 489,11, 483,91, 4 rdzenie. ale wykorzystanie pamięci i procesor są minimalne

Instancje Postfix od 16 do 32

Może to zabrzmi trochę szalenie, ale powinieneś:

1. Zmniejsz rejestrowanie do niezbędnego minimum. Niech syslog rejestruje tylko mail.err lub wyższy.
2. Dodaj więcej pamięci RAM. Tak, Postfix go nie potrzebuje, ale dodatkowa pamięć RAM oznacza dodatkową pamięć podręczną stron dla jądra.
3. Nie wspomniałeś, jaki system plików znajduje się na / dev / sdb (co też ma znaczenie), ale zdecydowanie przełącz go na noatime, co powinno przynajmniej trochę zmniejszyć obciążenie.
4. Zobacz, jak duży jest twój / var / spool / postfix. Jeśli jest poniżej kilku koncertów, rozważ przeniesienie go na ramdysk.

Muszę się nie zgodzić z tymi, które sugerowały użycie dysku RAM dla „/ var / spool / postfix”. Oznacza to, że cała kolejka poczty będzie przechowywana w pamięci RAM. Jeśli serwer ulegnie awarii lub straci moc, wiadomości w kolejce znikną na zawsze. Jest to naprawdę złe z perspektywy klienta / użytkownika, ponieważ wiadomość została już pomyślnie zaakceptowana do dostarczenia. Co gorsza, Twój serwer nie wyśle ​​powiadomienia, że ​​wiadomość e-mail została odesłana lub nie mogła zostać dostarczona, ponieważ kolejka będzie pusta po ponownym uruchomieniu serwera.

Zamiast tego dodałbym tyle szybkich dysków, na ile możesz sobie pozwolić; Naprawdę nie jestem w stanie oszacować, ile będziesz potrzebować z podanych informacji. Z powyższego wyjścia „iostat” wygląda na to, że wykonujesz ~ 120 IOPS do 'sdb' (suma r / siw / s). Można rozsądnie oszacować, że pojedynczy dysk SCSI lub FC 15k RPM obsłuży 150 IOPS. Zaczynam od 5 dysków SCSI 15k RPM i porządnego kontrolera RAID. Skonfiguruj go jako RAID-10 na 4 dyskach z 1 hot spare. Nie jestem pewien, czy to całkowicie rozwiąże twój problem, ale na pewno nie pogorszy go.

Uruchom postfiks pod jakimś profilerem (gprof?) Lub zajrzyj do dzienników. Postfix rejestruje wiele informacji o taktowaniu, które mogą wskazywać, gdzie jest zawieszenie. Typowe miejsca do patrzenia to:

1. Wydajność dysku. Może być czas na RAID-10 dla twojej kolejki.
2. Jakikolwiek sieciowy We / Wy na wiadomościach. Czarne listy DNS? SAV?
3. Milters i inne filtry, które zainstalowałeś.
4. Uwierzytelnianie i wyszukiwanie UID odbywa się przez sieć lub proces (ldap, sql).
5. nie używa proxy: dla wolnych map (jak wyżej)

Milion wiadomości dziennie to około 11 na sekundę, przy założeniu stałej przepustowości. Sam Postfix powinien być w stanie obsłużyć co najmniej rząd wielkości większy niż na podstawowym serwerze. Podejrzewam, że masz coś więcej niż tylko postfiks lub bardzo nierównomiernie rozłożone szczyty przepustowości.

Twoja sytuacja z pewnością wygląda na mocno związany z serwerem we / wy. Tego należy się spodziewać w przypadku MTA, który musi wykonać wiele małych zapisów, aby zagwarantować, że nie straci poczty.

Poświęć trochę czasu na dostrojenie We / Wy zarówno na, jak /var/spool/postfixi na /var/log. Najlepszą praktyką w przypadku zajętych serwerów Postfix jest rozdzielenie dwóch różnych wrzecion i upewnienie się, że włączone jest rejestrowanie asynchroniczne. poprzedź nazwę pliku dziennika dziennika poczty myślnikiem w systemie Linux.

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

lub podobne.

Jeśli używasz amavisd-new, upewnij się, że jego obszar roboczy znajduje się w systemie plików tmpfs. Zwykle to zakładamy /tmp/vscan/. Jest to bezpieczne, ponieważ amavisd-new nie zwraca odpowiedzi końca danych, dopóki przeskakiwanie po filtrze nie przyjmie komunikatu.

Niektóre osoby zalecają noatimeopcje montowania buforu Postfix. Jest to potencjalnie nierozsądne ze względu na sposób, w jaki poprawka zależy od semantyki systemu plików. Zobacz na przykład http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Zdecydowanie wygląda na to, że podsystem dyskowy powinien być przynajmniej częścią problemu. Ze względu na sposób, w jaki postfix przetasowuje pliki wokół / var, sugerowałbym googling w celu „ulepszenia systemu plików ext3” (przynajmniej ustawienia Noatime i Writeback), aby sprawdzić, czy nie możesz zwiększyć wydajności na poziomie systemu plików.

Mam dwa klastry serwerów, które podwójnie obsługują DNS i wychodzące SMTP dla wiadomości e-mail przeznaczonych dla klientów i uruchamiają 250 000 wiadomości dziennie (2–10 tys. Godzin), gdzie nie ma takiego powiązania we / wy.

Wygląda mi jak szyjka butelki do przechowywania.

Iowait z 99,88 mówi ci, że twój system spędza dużo czasu czekając na twoje miejsce.

Zgadzam się z Billem Weissem. Powinieneś przyjrzeć się konfiguracji raid10 dla kolejki.

lub zacznij od

vmstat 1

„iostat 1” sugerowany przez moshen jest również dobry

z twoich statystyk byłoby fajnie szybszy podsystem dyskowy. raid-10 na 6-8 dyskach 15k rpm może z pamięcią podręczną, kilkoma koncertami pamięci na pokładzie.

zamontuj swój katalog buforowy za pomocą opcji noatime, nodiratime. rozważ dostrojenie lub zmianę systemu plików, aby obsługiwał wiele małych [zakładam] plików.

Brian

Naprawdę potrzebujesz szybszego dysku lub najlepiej przejść do rozwiązania rajdowego. Co to za serwer?

James

Jeśli korzystasz z amavisa do filtrowania spamu i wirusów, powinieneś zwiększyć liczbę jednoczesnych procesów amavis. Zgodnie z twoją konfiguracją może być konieczne zwiększenie zarówno liczby procesów smtp-amavis z postfix master.cf, jak i odpowiednich ustawień w amavis.conf.

Ile rdzeni w pudełku i jakie jest rzeczywiste obciążenie? Jaka jest faktyczna szybkość wysyłania wiadomości?

Podobnie jak większość, moją pierwszą myślą jest dysk, więc sprawdź to.

Przyczyną może być jednak wykorzystanie sieci, podobnie jak duże obciążenie przerwaniem (zła karta?), Więc sprawdź je. Przekonałem się, że nawet w przypadku skromnego serwera pocztowego szybki serwer buforujący DNS (jestem częściowo „niezwiązany”) na tym samym urządzeniu pomaga zmniejszyć opóźnienia i obciążenie sieci.

gdy wykonujesz 630 odczytów i 1042 zapisów na sekundę, zdecydowanie sugeruję zwiększenie pamięci w systemie (aby lepiej obsługiwać system operacyjny i pamięć RAM), a następnie uczynienie z folderu postfiksa ramdysku.

Sugeruje również umieszczenie dzienników poczty na własnej partycji, jeśli nie na własnym dysku.

To nie jest problem IO, to problem z konfiguracją Postfiksa. Prosisz o zrobienie zbyt wiele naraz i stworzenie wąskiego gardła dla siebie. Sprawdź readme dostrajania wydajności Postfix i / lub opublikuj plik main.cf, abyśmy mogli Ci pomóc.

wygląda na to, że masz podejrzany dysk. Twój serwer wykonuje tylko 72 żądania odczytu / s i 42 zapisu / sekundę. Mój stacjonarny dysk twardy Seagate 7200 RPM może wykonać ponad 100 losowych żądań odczytu / zapisu na sekundę i nadal sobie z tym poradzić.

Spróbuj zamontować szpulę na sda i sprawdź, czy ładunek się poprawi.

Ale zanim wydasz więcej pieniędzy na dysk, wykonaj następujące czynności:

1. Uruchom qshape aktywne, qshape odroczone i qshape przychodzące i daj nam znać sumę każdego polecenia.

   Niezwykle wysoka liczba wiadomości w odroczonej kolejce oznacza, że ​​spamer może użyć twojego serwera pocztowego do przekazywania spamu (np. Wysyłanie wiadomości e-mail do nieistniejącej domeny, co spowoduje, że postfix będzie próbował ponownie).

2. Upewnij się, że twój serwer pocztowy nie znajduje się na czarnej liście ( http://www.mxtoolbox.com/blacklists.aspx )

3. Sprawdź czas odpowiedzi DNS i uruchom lokalną pamięć podręczną DNS.

   Serwer pocztowy dość intensywnie korzysta z DNS. Zrób dig somedomain.com mx to na kilku różnych hostach. Ogólnie czas odpowiedzi powinien być mniejszy niż 100 - 400 ms. Jeśli otrzymasz wyższą odpowiedź, twój DNS może nie działać dobrze. Wypróbuj inny DNS (możesz wypróbować google 8.8.8.8 lub OpenDNS: 208.67.222.222)

4. Sprawdź swoją sieć. (np. ifconfig) i zobacz, ile pakietów błędów. Sprawdź, czy Twój link jest nasycony lub ukształtowany. Sprawdź, czy w dziennikach poczty była jakaś duża liczba operacji przekroczenia limitu czasu. Wykonaj tcpdump i upewnij się, że pakiety nie gubią się ani nie są ponownie przesyłane.

5. Czy możesz nam powiedzieć, czy konsola reaguje (np. Kiedy wpiszesz jakieś polecenie, jak szybko system przekazuje ci informację zwrotną)?

   Zasadniczo problem z siecią (np. DNS) spowoduje gwałtowny wzrost obciążenia, ale system nadal reaguje.