Hiệu suất hậu tố

Chạy postfix trên Ubuntu, gửi rất nhiều thư (~ 1 triệu tin nhắn) mỗi ngày. tải cực kỳ cao nhưng không nhiều về tải cpu và bộ nhớ. Bất cứ ai trong một tình huống tương tự và biết làm thế nào để loại bỏ nút cổ chai?

Tất cả thư trên máy chủ này là gửi đi.

Tôi sẽ phải giả sử nút cổ chai là đĩa.

Chỉ cần một bản cập nhật, đây là giao diện của 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

Những con số này có phù hợp với hiệu suất mà bạn mong đợi từ một đĩa không?

sdb được dành riêng cho postfix.

Tôi nghĩ rằng đó là xáo trộn hàng đợi, từ đến-> hoạt động-> hoãn lại

Thêm chi tiết từ các câu hỏi:

Máy chủ: CPU bốn lõi Xeon (R) CPU E5405 @ 2.00GH với ram 4 GB

Tải trung bình: 464,88, 489,11, 483,91, 4 lõi. nhưng việc sử dụng bộ nhớ và cpu là tối thiểu

Các trường hợp hậu tố giữa 16 - 32

Điều này nghe có vẻ hơi điên rồ, nhưng bạn nên:

1. Từ chối đăng nhập đến mức tối thiểu bạn cần. Tạo nhật ký hệ thống chỉ đăng nhập mail.err hoặc cao hơn.
2. Thêm RAM. Có, Postfix không cần nó, nhưng RAM thêm có nghĩa là bộ đệm trang phụ cho kernel.
3. Bạn đã không đề cập đến hệ thống tập tin nào trên / dev / sdb (cũng có vấn đề), nhưng chắc chắn chuyển đổi nó sang noatime, điều này sẽ làm giảm tải ít nhất một chút.
4. Xem mức độ lớn của bạn / var / spool / postfix. Nếu dưới một vài gig, hãy xem xét chuyển nó sang ramdisk.

Tôi phải không đồng ý với những người đã đề xuất sử dụng đĩa RAM cho "/ var / spool / postfix". Điều này có nghĩa là toàn bộ hàng đợi thư của bạn sẽ được lưu trữ trong RAM. Nếu máy chủ của bạn gặp sự cố hoặc mất nguồn, tin nhắn trong hàng đợi sẽ biến mất vĩnh viễn. Điều này thực sự tệ từ góc độ khách hàng / người dùng vì tin nhắn đã được chấp nhận thành công để gửi. Tồi tệ hơn, máy chủ của bạn sẽ không gửi thông báo cho biết rằng email bị trả lại hoặc không thể được gửi vì hàng đợi sẽ trống khi máy chủ sao lưu.

Thay vào đó, tôi sẽ thêm nhiều đĩa nhanh nhất có thể; Tôi thực sự không thể ước tính số lượng bạn sẽ cần với thông tin được cung cấp. Từ đầu ra "i bổ sung" ở trên, có vẻ như bạn đang thực hiện ~ 120 IOPS thành 'sdb' (tổng của r / s và w / s). Bạn có thể ước tính một cách hợp lý rằng một đĩa SCK hoặc FC 15k RPM duy nhất sẽ xử lý 150 IOPS. Tôi sẽ bắt đầu với 5 đĩa SCM 15k RPM và bộ điều khiển RAID phong nha. Thiết lập nó dưới dạng RAID-10 trên 4 ổ đĩa với 1 dự phòng nóng. Tôi không chắc chắn rằng điều này sẽ giải quyết hoàn toàn vấn đề của bạn, nhưng nó chắc chắn sẽ không làm cho nó tồi tệ hơn.

Chạy postfix dưới một số profiler (gprof?) Hoặc tìm trong nhật ký. Postfix ghi lại rất nhiều thông tin về thời gian có thể cho bạn biết vị trí của nó. Những nơi phổ biến để tìm là:

1. Hiệu suất đĩa. Có thể là thời gian cho RAID-10 cho hàng đợi của bạn.
2. Bất kỳ loại IO mạng trên tin nhắn. Danh sách đen DNS? SAV?
3. Bộ lọc và các bộ lọc khác bạn đã cài đặt.
4. Xác thực và tra cứu UID đang được thực hiện qua mạng hoặc theo một quy trình (ldap, sql).
5. không sử dụng proxy: đối với bản đồ chậm (như trên)

Một triệu tin nhắn mỗi ngày là khoảng 11 mỗi giây, giả sử thông lượng là không đổi. Postfix tự nó sẽ có thể xử lý ít nhất một thứ tự cường độ lớn hơn so với phần cứng máy chủ cấp nhập cảnh. Vì vậy, tôi nghi ngờ bạn có nhiều hơn chỉ là postfix đang chạy, hoặc các đỉnh thông lượng phân phối rất không đồng đều.

Tình huống của bạn chắc chắn trông giống như một máy chủ bị ràng buộc I / O. Điều này được mong đợi với một MTA, cần tạo ra nhiều văn bản nhỏ để đảm bảo rằng nó sẽ không bị mất thư.

Dành thời gian để điều chỉnh I / O trên cả hai /var/spool/postfixvà /var/log. Thực tiễn tốt nhất cho các máy chủ postfix bận rộn là tách hai trục chính khác nhau và đảm bảo rằng đăng nhập không đồng bộ được bật. tiền tố tên logfile cho nhật ký thư của bạn với dấu gạch ngang trên Linux.

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

hoặc tương tự.

Nếu bạn đang sử dụng tính năng mới, hãy đảm bảo vùng làm việc của nó nằm trên hệ thống tệp tmpfs. Chúng tôi thường đặt nó trên /tmp/vscan/. Điều này là an toàn, vì amav điều khoản mới không trả về phản hồi cuối dữ liệu cho đến khi hop (bộ lọc sau) hạ lưu đã chấp nhận thông báo.

Một số người đề xuất noatimecác tùy chọn gắn kết cho bộ đệm postfix. Điều này có khả năng không khôn ngoan, do cách postfix phụ thuộc vào ngữ nghĩa hệ thống tệp. Xem ví dụ http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Nó chắc chắn trông giống như hệ thống con đĩa của bạn ít nhất nên được xem là một phần của vấn đề. Do cách postfix xáo trộn các tập tin xung quanh / var, tôi sẽ đề nghị googling cho "tinh chỉnh hệ thống tập tin ext3" (ít nhất là thiết lập noatime và writounce) để xem liệu bạn có thể tăng hiệu suất ở cấp hệ thống tập tin không.

Tôi có hai cụm máy chủ tăng gấp đôi DNS và SMTP đi cho email dành cho khách hàng và chạy 250k tin nhắn hàng ngày (2k-10k / giờ) mà không có nơi nào liên kết I / O đó.

Trông giống như một cổ chai hiệu suất lưu trữ với tôi.

Iowait 99,88 cho bạn biết rằng hệ thống của bạn đang dành rất nhiều thời gian chờ đợi cho bộ nhớ của bạn.

Tôi đồng ý với Bill Weiss. Bạn nên xem xét một thiết lập raid10 cho hàng đợi.

hoặc bắt đầu với

vmstat 1

"iuler 1" được đề xuất bởi moshen cũng tốt

từ thống kê của bạn rõ ràng hệ thống con đĩa nhanh hơn sẽ tốt đẹp. raid-10 trên các đĩa 6-8 15k vòng / phút có thể với một số bộ nhớ cache, vài hợp đồng bộ nhớ trên máy bay.

gắn thư mục spool của bạn với các tùy chọn noatime, gật đầu. xem xét điều chỉnh hoặc thay đổi hệ thống tệp của bạn để xử lý nhiều tệp [tôi giả định] nhỏ.

Brian

Bạn thực sự cần phải có một đĩa nhanh hơn, hoặc tốt nhất là di chuyển đến một giải pháp đột kích. Đây là loại máy chủ gì?

James

Nếu bạn đang chạy amavis để lọc thư rác + vi-rút, bạn nên tăng số lượng quy trình amavis đồng thời. Theo thiết lập của bạn, bạn có thể cần tăng cả số lượng quy trình smtp-amavis từ postfix master.cf, và cả cài đặt có liên quan trong amavis.conf.

Có bao nhiêu lõi trong hộp, và tải thực tế là bao nhiêu? Tỷ lệ thực tế bạn nhận được tin nhắn được gửi là gì?

Giống như hầu hết, suy nghĩ đầu tiên của tôi là đĩa, vì vậy hãy kiểm tra xem.

Tuy nhiên, việc sử dụng mạng có thể là nguyên nhân, vì có thể tải gián đoạn cao (thẻ xấu?), Vì vậy hãy kiểm tra chúng. Tôi đã thấy rằng ngay cả đối với một máy chủ thư khiêm tốn, việc có một máy chủ DNS lưu trữ nhanh (tôi là một phần của "không ràng buộc") trên cùng một hộp giúp giảm bớt độ trễ và tải mạng.

với bạn thực hiện 630 lần đọc và 1042 lần ghi mỗi giây, tôi chắc chắn khuyên bạn nên tăng bộ nhớ trong hệ thống (để xử lý tốt hơn hệ điều hành & ổ đĩa ram) và sau đó biến thư mục postfix của bạn thành ramdisk.

Cũng sẽ đề nghị đặt nhật ký thư của bạn trên phân vùng riêng của họ nếu không hoàn toàn là đĩa riêng của họ.

Đây không phải là vấn đề IO, đây là vấn đề cấu hình postfix. Bạn đang yêu cầu nó làm quá nhiều tất cả cùng một lúc và tạo ra một nút cổ chai cho chính mình. Kiểm tra readme điều chỉnh hiệu suất postfix và / hoặc đăng main.cf của bạn để chúng tôi có thể giúp đỡ.

Có vẻ như bạn đã có một đĩa tinh ranh. Máy chủ của bạn chỉ thực hiện 72 yêu cầu đọc / giây & 42 ghi / giây. Ổ cứng máy tính để bàn seagate 7200 RPM của tôi có thể thực hiện hơn 100 yêu cầu đọc / ghi ngẫu nhiên mỗi giây và vẫn đối phó với nó.

Hãy thử gắn ống chỉ trên sda và xem liệu tải có tốt hơn không.

Nhưng trước khi bạn vung tiền nhiều hơn trên đĩa, hãy làm như sau:

1. Chạy qshape hoạt động, qshape hoãn lại và qshape đến và cho chúng tôi biết tổng số của mỗi lệnh.

   Số lượng thư cao bất thường trong hàng đợi bị trì hoãn có nghĩa là máy chủ thư của bạn có thể được sử dụng bởi người gửi thư rác để chuyển tiếp thư rác của họ (ví dụ: gửi email đến tên miền không tồn tại sẽ khiến cho hậu tố của bạn thử lại nhiều lần).

2. Đảm bảo rằng máy chủ thư của bạn không nằm trong danh sách đen ( http://www.mxtoolbox.com/blacklists.aspx )

3. Kiểm tra thời gian phản hồi DNS & Chạy bộ đệm DNS cục bộ.

   Máy chủ mail sử dụng DNS khá nhiều. Đừng dig somedomain.com mx chạy nó trên một vài máy chủ khác nhau. Nói chung thời gian đáp ứng nên dưới 100 - 400ms. Nếu bạn nhận được phản hồi cao hơn, DNS của bạn có thể không hoạt động tốt. Hãy thử DNS khác nhau (bạn có thể dùng thử 8.8.8.8 hoặc OpenDNS của Google: 208.67.222.222)

4. Kiểm tra mạng của bạn. (ví dụ ifconfig) và xem có bao nhiêu gói lỗi. Kiểm tra xem liên kết của bạn đã bão hòa hoặc hình. Kiểm tra xem có bất kỳ số lượng lớn thời gian hoạt động trên nhật ký thư. Làm tcpdump và đảm bảo các gói không bị mất hoặc truyền lại.

5. Bạn có thể cho chúng tôi biết bàn điều khiển có phản hồi không (ví dụ: khi bạn gõ một số lệnh, hệ thống sẽ cung cấp cho bạn thông tin phản hồi nhanh như thế nào)?

   Nói chung, sự cố mạng (ví dụ DNS) sẽ khiến tải tăng vọt, nhưng hệ thống vẫn phản hồi.