Кстати тоже будет не лишним проверить, если лог лежит в /var/log/exim/main.log, то в bash конструкция:
for x in `cat /var/log/exim/main.log | grep '@mail.ru' | awk '{print $3}'`; do cat /var/log/exim/mainlog | grep $x; done
даст искомую выборку по отправлениям писем на mail.ru. Или выборка отправленных на конкретный ящик писем:
for x in `cat /var/log/exim/main.log | grep 'mail_adres@mail.ru' | awk '{print $3}'`; do cat /var/log/exim/mainlog | grep $x; done
Еще помимо mainlog как правило есть reject.log и info.log
И еще момент - как правило логи сворачиваются раз в сутки, соответственно выборки выше - это выборка за "сегодня".
Увы, несмотря на все старания mail.ru (http://habrahabr.ru/company/mailru/blog/128445/), иногда ответа от них можно ждать очень долго.
Как вариант, попробуйте, если есть такая возможность, поменять ip с которого exim отправляет письма, если у вас на сервере несколько ip адресов, то в конфигурации exim (файл configure), в разделе transport укажите директиву interface (подробнее тут http://www.exim.org/exim-html-current/doc/html/spec_html/ch30.html)
Так же ради интереса, маловероятно, но все же mail.ru может молча резать письмо исходя просто из лингвистического анализа контента письма и его заголовков, можно попробовать отправить практически пустое письмо следующим скриптом, предварительно поменяв адреса отправителя и получателя на актуальные:
<?php $to = 'mail_adres@mail.ru'; $subject = 'Test'; $message = 'Hello!! This is a test email.'; $headers = 'From: info@site.ru' . "\r\n" . 'Reply-To: info@site.ru' . "\r\n" . 'X-Mailer: PHP/' . phpversion(); if(!mail($to, $subject, $message, $headers)) die("mail error"); ?>
Возможно стоит проверится так же на блокировку конкретного ip различными сервисами, к примеру
http://whatismyipaddress.com/blacklist-check
Так же может имеет смысл попробовать объяснить хостеру ситуацию, и попросить бесплатно на пару часов еще один ip адрес и с попробовать отправить с него, как писал выше, указав его в настройках exim
Совершенно верно, письмо было удачно передано на mxs.mail.ru, а вот дальнейшую его судьбу, особенно если в веб интерфейсе на mail.ru его нет даже в папке "спам" сможет уточнить только тех. поддержка mail.ru
Munin по умолчанию может только подтвердить версию о том, что память действительно заканчивается, самый надежный способ выяснить кем используется память - это top и ps в момент возникновения проблем.
Если почтовый сервер exim - то логи искать имеет смысд в /var/log/exim/
А вообще относительно mail.ru есть к примеру отличная заметка от mail.ru
http://habrahabr.ru/company/mailru/blog/120389/
Как вариант - возможно столь толстый файл имеет смысл переместить в mysql, если он конечно содержит некие структурированные данные, а mysql уже есть у вас на сервере и настроен.
Только путь внимательно проверьте, как никак удаление операция часто необратимая.
find /var/www/user1/data/www/site1.com/papka/ -delete
Да, извиняюсь, с mysqlnd накладок пока что быть не должно, netwind прав.
Через grep + sed удобно, причем sed сам может создавать резервные копии.
Но возможно действительно имеет смысл откатится до 5.2.17 и далее поэтапно перетаскивать сайты на 5.3, т.к. как верно уже отметили там будет много deprecated, плюс в 5.3 новый драйвер для работы с mysql используется, не покатят старые конструкции.
