У меня есть сценарий Perl, который отправляет почту в список рассылки.
На моем старом выделенном сервере он работал нормально и в основном отправлял одно электронное письмо в секунду. Недавно я переключился на новый выделенный сервер с примерно такими же характеристиками, и он работает очень медленно, примерно одно письмо каждые 30 секунд. Я создал тестовый скрипт, чтобы посмотреть, какая часть занимает больше всего времени:
open(MAIL,"| /usr/sbin/sendmail -tv -d8.7 $recipient_email");
print MAIL <<EOF;
From:Test Sender <$sender>
To:$recipient_email
Subject:Testing
Justw ant to see how long this takes
EOF
close(MAIL);
-D8.7 есть опция отладки, которая позволяет мне наблюдать за выводом скрипта. Я вставлю это здесь, есть 3 точки, которые оба слишком долго висят, я отмечу их здесь:
dns_getcanonname(receiving_server.com, trymx=1)
dns_getcanonname: trying receiving_server.com. (A)
5 секунд задержка здесь ДА
dns_getcanonname: receiving_server.com
getmxrr([127.0.0.1], droplocalhost=1)
andrew@receiving_server.com... Connecting to [127.0.0.1] via relay...
220 my_server.com ESMTP Sendmail 8.13.8/8.13.8; Fri, 18 May 2012 06:55:04 +0200
>>> EHLO localhost.localdomain
250-my_server.com Hello localhost.localdomain [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<root@localhost.localdomain> SIZE=115
10 секунд задержка здесь
250 2.1.0 <root@localhost.localdomain>... Sender ok
>>> RCPT To:<andrew@receiving_server.com>
>>> DATA
5 секунд задержка здесь
250 2.1.5 <andrew@receiving_server.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 q4I4t4Lu014501 Message accepted for delivery
andrew@receiving_server.com... Sent (q4I4t4Lu014501 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 my_server.com closing connection
Насколько я могу судить, мои / etc / hosts и /etc/resolv.conf кажутся в порядке, и это единственное, что, по мнению Google, может быть сломано, у кого-нибудь есть идеи?
Это выглядит как
Удаленный сервер такой же, как раньше? Вы видите этот сервер?
Вы запускали tcpdump на этом интерфейсе, чтобы увидеть, есть ли какая-либо активность протокола во время пробелов? Попробуйте это (как root) -
# tcpdump -vvv -w output.pcap -i eth0 'port not 22'
Это захватит весь трафик, кроме трафика сеанса SSH, и выведет его в файл output.pcap.
Я не думаю, что есть шанс, что вы перешли на IP-адрес, который находится где-то в черном списке? Сайты, подобные следующим, могут помочь вам узнать -