Kinerja postfix

Menjalankan postfix di ubuntu, mengirim banyak surat (~ 1 juta pesan) per hari. bebannya sangat tinggi tetapi tidak banyak dalam hal cpu dan memori. Adakah yang berada dalam situasi yang sama dan tahu cara menghilangkan hambatan?

Semua email di server ini keluar.

Saya harus mengasumsikan bottleneck adalah disk.

Sekedar pembaruan, inilah tampilan 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

Apakah angka-angka ini sesuai dengan kinerja yang Anda harapkan dari satu disk?

sdb didedikasikan untuk postfix.

Saya pikir ini adalah pengocokan antrian, dari masuk-> aktif-> ditangguhkan

Lebih detail dari pertanyaan:

Server: Quad core Xeon (R) CPU E5405 @ 2.00GH dengan ram 4 GB

Rata-rata beban: 464,88, 489,11, 483,91, 4 core. tetapi pemanfaatan memori dan cpu minimal

Contoh postfix antara 16 - 32

Ini mungkin terdengar agak gila, tetapi Anda harus:

1. Matikan logging ke minimum yang Anda butuhkan. Buat syslog hanya mencatat mail.err atau lebih tinggi.
2. Tambahkan lebih banyak RAM. Ya, Postfix tidak membutuhkannya, tetapi RAM tambahan berarti cache halaman tambahan untuk kernel.
3. Anda tidak menyebutkan filesystem apa yang aktif di / dev / sdb (yang penting juga), tapi pasti beralih ke noatime, yang seharusnya mengurangi beban setidaknya sedikit.
4. Lihat seberapa besar / var / spool / postfix Anda. Jika masih dalam beberapa pertunjukan, pertimbangkan untuk memindahkannya ke ramdisk.

Saya harus tidak setuju dengan mereka yang menyarankan menggunakan disk RAM untuk "/ var / spool / postfix". Ini berarti bahwa seluruh antrian email Anda akan disimpan dalam RAM. Jika server Anda mogok, atau kehilangan daya, pesan dalam antrian hilang selamanya. Ini benar-benar buruk dari perspektif klien / pengguna karena pesan telah berhasil diterima untuk pengiriman. Lebih buruk lagi, server Anda tidak akan mengirim pemberitahuan yang menyatakan bahwa email memantul atau tidak dapat dikirim karena antrian akan kosong ketika server kembali.

Sebagai gantinya, saya akan menambahkan disk cepat sebanyak yang Anda mampu; Saya tidak dapat memperkirakan berapa banyak yang Anda perlukan dengan informasi yang diberikan. Dari output "iostat" di atas, sepertinya Anda melakukan ~ 120 IOPS ke 'sdb' (jumlah r / s dan w / s). Anda dapat memperkirakan bahwa satu disk RPM SCSI atau FC 15k tunggal akan menangani 150 IOPS. Saya akan mulai dengan 5 disk RPM SCSI 15k dan pengontrol RAID yang layak. Atur sebagai RAID-10 di 4 drive dengan 1 cadangan panas. Saya tidak yakin ini akan sepenuhnya menyelesaikan masalah Anda, tetapi pasti tidak akan memperburuknya.

Jalankan postfix di bawah beberapa profiler (gprof?), Atau lihat di log. Postfix mencatat banyak informasi pengaturan waktu yang mungkin memberi tahu Anda di mana penahanannya. Tempat umum untuk melihat adalah:

1. Kinerja disk. Mungkin saatnya untuk RAID-10 untuk antrian Anda.
2. IO jaringan apa pun pada pesan. Daftar hitam DNS? SAV?
3. Penghilang dan filter lain yang telah Anda instal.
4. Otentikasi dan pencarian UID dilakukan melalui jaringan atau ke suatu proses (ldap, sql).
5. tidak menggunakan proxy: untuk peta lambat (seperti di atas)

Satu juta pesan sehari adalah sekitar 11 per detik, dengan asumsi throughput konstan. Postfix dengan sendirinya harus mampu menangani setidaknya urutan besarnya lebih besar dari pada perangkat keras server entry-level. Jadi saya curiga Anda memiliki lebih dari sekedar postfix yang berjalan, atau puncak throughput yang didistribusikan sangat tidak merata.

Situasi Anda tentu terlihat seperti server yang sangat terikat I / O. Ini diharapkan dengan MTA, yang perlu membuat banyak tulisan kecil untuk menjamin bahwa itu tidak akan kehilangan surat.

Luangkan waktu untuk menyempurnakan I / O pada keduanya /var/spool/postfixdan /var/log. Praktik terbaik untuk server postfix sibuk adalah memisahkan keduanya di spindel yang berbeda, dan untuk memastikan bahwa logging asinkron diaktifkan. awali nama file log untuk log surat Anda dengan tanda hubung di Linux.

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

atau serupa.

Jika Anda menggunakan amavisd-new, pastikan area kerjanya ada pada sistem file tmpfs. Kami biasanya memakainya /tmp/vscan/. Ini aman, karena amavisd-new tidak mengembalikan respons data akhir hingga hop hilir (pasca-filter) menerima pesan.

Beberapa orang merekomendasikan noatimeopsi pemasangan untuk spool postfix. Ini berpotensi tidak bijaksana, karena cara postfix bergantung pada semantik sistem file. Lihat misalnya http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Itu pasti terlihat seperti subsistem disk Anda setidaknya harus dilihat sebagai bagian dari masalah. Karena cara postfix mengocok file sekitar / var, saya akan menyarankan googling untuk "tweak sistem file ext3" (setidaknya mengatur noatime dan writeback) untuk melihat apakah Anda tidak dapat meningkatkan kinerja di tingkat sistem file.

Saya memiliki dua kelompok server yang menggandakan DNS tugas dan SMTP keluar untuk email yang ditentukan pelanggan dan menjalankan 250k pesan setiap hari (2k-10k / jam) dengan tempat dekat seperti I / O bindup semacam itu.

Sepertinya leher botol kinerja penyimpanan bagi saya.

The iowait of 99.88 memberitahu Anda bahwa sistem Anda menghabiskan banyak waktu menunggu di penyimpanan Anda.

Saya setuju dengan Bill Weiss. Anda harus melihat ke dalam pengaturan raid10 untuk antrian.

atau mulai dengan

vmstat 1

"iostat 1" yang disarankan oleh moshen juga bagus

dari statistik Anda jelas subsistem disk lebih cepat akan lebih baik. raid-10 pada 6-8 15k rpm disk mungkin dengan beberapa cache, beberapa pertunjukan memori on-board.

pasang direktori spool Anda dengan opsi noatime, nodiratime. pertimbangkan menyetel atau mengubah sistem file Anda untuk menangani banyak file kecil [saya berasumsi].

Brian

Anda benar-benar perlu mendapatkan disk yang lebih cepat, atau lebih baik pindah ke solusi serangan. Server macam apa ini?

James

Jika Anda menjalankan amavis untuk memfilter spam + virus, Anda harus meningkatkan jumlah proses amavis bersamaan. Menurut pengaturan Anda, Anda mungkin perlu meningkatkan jumlah proses smtp-amavis dari postfix master.cf, dan juga pengaturan yang relevan di amavis.conf.

Berapa core di dalam kotak, dan berapa beban sebenarnya? Berapa nilai aktual Anda menerima pesan?

Seperti kebanyakan, pikiran pertama saya adalah disk, jadi periksa itu.

Namun, pemanfaatan jaringan mungkin menjadi penyebabnya, karena mungkin beban interupsi yang tinggi (kartu buruk?), Jadi periksa itu. Saya telah menemukan bahwa bahkan untuk server email sederhana, memiliki server DNS caching cepat (saya tidak setuju dengan "tidak terikat") pada kotak yang sama membantu mengurangi latensi dan beban jaringan.

dengan Anda melakukan 630 membaca dan 1042 menulis per detik, saya pasti menyarankan menumpuk memori Anda di sistem (untuk lebih baik menangani OS & drive ram) dan kemudian membuat folder postfix Anda menjadi ramdisk.

Sarankan juga meletakkan log surat Anda di partisi mereka sendiri jika tidak sepenuhnya disk mereka sendiri.

Ini bukan masalah IO, ini masalah konfigurasi postfix. Anda memintanya untuk melakukan terlalu banyak sekaligus dan menciptakan hambatan untuk diri sendiri. Lihat readme penyetelan kinerja postfix dan / atau posting main.cf Anda sehingga kami dapat membantu.

Sepertinya Anda punya disk yang cerdik. Server Anda hanya melakukan 72 permintaan baca / detik & 42 tulis / detik. HDD desktop seagate 7200 RPM saya dapat melakukan 100+ permintaan baca / tulis acak per detik dan masih mengatasinya.

Coba pasang spul di sda dan lihat apakah bebannya membaik.

Tetapi sebelum Anda mengeluarkan lebih banyak uang pada disk, lakukan hal berikut:

1. Jalankan qshape aktif, qshape ditangguhkan, dan qshape masuk dan beri tahu kami total dari setiap perintah.

   Jumlah mail yang sangat tinggi dalam antrian yang ditangguhkan berarti server email Anda mungkin digunakan oleh spammer untuk menyampaikan spam mereka (mis. Mengirim email ke domain yang tidak ada yang akan menyebabkan postfix Anda mencoba lagi dan lagi).

2. Pastikan server email Anda tidak masuk daftar hitam ( http://www.mxtoolbox.com/blacklists.aspx )

3. Periksa waktu respons DNS & Jalankan cache DNS lokal.

   Server email menggunakan DNS cukup banyak. Do dig somedomain.com mx Run di atas beberapa host yang berbeda. Umumnya waktu respons harus kurang dari 100 - 400ms. Jika Anda mendapatkan respons yang lebih tinggi, DNS Anda mungkin tidak berkinerja baik. Coba DNS lain (Anda bisa mencoba Google 8.8.8.8 atau OpenDNS: 208.67.222.222)

4. Periksa jaringan Anda. (mis. ifconfig) dan lihat berapa banyak paket kesalahan. Periksa apakah tautan Anda jenuh atau berbentuk. Periksa apakah ada operasi time out dalam jumlah besar pada log surat. Lakukan tcpdump dan pastikan paket tidak hilang atau dikirim kembali.

5. Bisakah Anda memberi tahu kami jika konsol responsif (mis. Ketika Anda mengetik beberapa perintah, seberapa cepat sistem memberi Anda umpan balik)?

   Umumnya masalah jaringan (mis. DNS) akan menyebabkan beban meroket, tetapi sistem masih responsif.