> Sep 2 13:00:47 ru amavis[87682]: (87682-15) TIMING [total 257879 ms] - > SMTP greeting: 25055 (10%)10, SMTP EHLO: 0 (0%)10, SMTP pre-MAIL: 0 (0%)10, > SMTP pre-DATA-flush: 7 (0%)10, > SMTP DATA: 24052 (9%)19, check_init: 25053 (10%)29, digest_hdr: 1 (0%)29, > digest_body: 0 (0%)29, > gen_mail_id: 21050 (8%)37, mime_decode: 21063 (8%)45, get-file-type1: 21 > (0%)45, decompose_part: 1 (0%)45, > parts_decode: 0 (0%)45, check_header: 2 (0%)45, AV-scan-1: 21058 (8%)53, > spam-wb-list: 5 (0%)53, > update_cache: 2 (0%)53, decide_mail_destiny: 25156 (10%)63, fwd-connect: > 64265 (25%)88, fwd-xforward: 1 (0%)88, > fwd-mail-pip: 5 (0%)88, fwd-rcpt-pip: 1 (0%)88, fwd-data-chkpnt: 0 (0%)88, > write-header: 2 (0%)88, > fwd-data-contents: 0 (0%)88, fwd-end-chkpnt: 4 (0%)88, prepare-dsn: 1 (0%)88, > main_log_entry: 12 (0%)88, > update_snmp: 2 (0%)88, SMTP pre-response: 31057 (12%)100, SMTP response: 0 > (0%)100, unlink-2-files: 1 (0%)100, > rundown: 2 (0%)100
> Machine does not look busy at all during those problems. Load is under 0.5 > and CPU is 90% idle. > Even small emails are affected. If the host is not busy, again, my primary suspect is a berkeley db. These multiples of 20..25 second delays, some at inexplicable sections, seem to coincide with updating a child process status in the nanny database. Try disabling it altogether: $enable_db=0; If that helps, consider upgrading libdb to a more recent version (along with the BerkeleyDB perl module). Mark
