Назад | Перейти на главную страницу

Сценарий Perl очень медленно отправляет почту через sendmail - одно письмо каждые 30 секунд

У меня есть сценарий 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, может быть сломано, у кого-нибудь есть идеи?

Это выглядит как

  1. Задержка разрешения имени через DNS
  2. Проверка получателя удаленным SMTP-сервером
  3. Проверка отправителя удаленным SMTP-сервером

Удаленный сервер такой же, как раньше? Вы видите этот сервер?

Вы запускали tcpdump на этом интерфейсе, чтобы увидеть, есть ли какая-либо активность протокола во время пробелов? Попробуйте это (как root) -

# tcpdump -vvv -w output.pcap -i eth0 'port not 22'

Это захватит весь трафик, кроме трафика сеанса SSH, и выведет его в файл output.pcap.

Я не думаю, что есть шанс, что вы перешли на IP-адрес, который находится где-то в черном списке? Сайты, подобные следующим, могут помочь вам узнать -

http://www.mxtoolbox.com/blacklists.aspx