Оптимизация работы почты. (NFS)

Почтовое сообщение как правило состоит из текста и вложений.

Обычно по объему больше занимают вложения и они закодированы в объёмно неэффективный base64. Хорошо если бы был какой-то почтовый архиватор, который отделяет вложения, перекодируя в бинарную последовательность, сохраняя ссылку на файл в сообщении на случай поиска по архиву. Там далее вложение может иметь совершенно разнообразный формат, к которому вопрос ещё найдётся ли эффективный компрессор, но уже гораздо лучше чем base64.

Текст воплне прекрасно может быть прекрасно сжат каким нибудь bz2, но эффективность сжатия сильно падает если текст в base64, включая зашифрованный текст. Да и как правило текстовая часть пренебрежимо мала по объёму чтобы ей заморачиваться.

Есть ли возможность стандартными средствами определять, письмо с вложением или нет, и если с вложением, класть вложение в специальную папку, а в письме указывать только ссылку на это вложение?

В Dovecot см. параметр mail_attachment_dir, mail_attachment_min_size и mail_attachment_hash. Заодно будет дедупликация из коробки. Будет хранить отдельно вложения. mdbox + mail_attachment_dir самый идеальный вариант на мой взгляд. Клиентам будет отдаваться нормально скомпонованное письмо, разумеется, в текст письма оно ссылку вставлять не будет.

При рассылке писем с вложениями(Даже если вложение меньше 1мб) нагрузка на диск доходит до 100%.

Поясните подробнее, что Вы имеете ввиду? Входящие письма, адресованные сразу всем (или значительной группе) Ваших пользователей? Исходящие письма? Или локальный обмен почтой (когда один пользователь отсылает письмо группе локальных пользователей)?

Проблема: При рассылке писем с вложениями

кто кому рассылает письма? Посылатели из интернета вам на почтовик? Локальные юзвери в интернет?

Вообще неудивительно, NFS sucks на большом объеме мелких файлов. Надо мутить какой-то RAM/tmpfs временный сторадж для кэша dovecot.

Локальные рассылки. Допустим сотрудник отдела «А» отправляет письмо 300 сотрудникам отдела «Б». Почта ложится

есть группа рассылки

vse@domain.ru - 600 юзеров departament@domain.ru 30 - 150 юзеров

Размер вложения 4мб.

Рассылка локальная/извне не имеет значения. Dovecot кладет каждое вложение каждому пользователю из рассылки в ящик, что вызывает статус D.

Ссылка на скриншот htop/atop : https://ibb.co/grzYmzC

1) Какая версия NFS?

2) NFS под гигабит тюнился?

3) Оправданно ли использование LVM?

Тогда, наверное, самый дельный совет поступил от VinilNavigator - этот способ позволит радиально снизить трафик.

Ну и стандартные советы по тюнингу сети в целом и NFS в частности, как, например, здесь пишут.

Возможно тюнинг Dovecot частично и поможет, но разве письмо для рассылки примет не SMTP-сервер? Он же сформирует стопятьсот одинаковых писем для всего списка рассылки и начнет их доставлять конкретным пользователям, чем уже сформирует нехилую нагрузку...

Я бы еще озадачился фильтром на входящие письма для SMTP-сервера, который размещал бы вложения на внутреннем Web-сервере и замещал вложения в письме ссылками на файлы. Это снизит объемы пересылаемой информации в десятки раз. Файлы на Web-сервере проще дедуплицировать, так что у вас еще и объемы хранимой информации снизятся в разы. Правда не уверен что этот функционал реализован в каком-либо SMTP-сервере, скорее всего вам придется писать фильтр самому, как когда-то пришлось делать мне :)

Еще когда-то делал специализированный почтовый relay, который учитывал текущую загрузку на сервере и вставал на паузу при достижении заданных порогов. Рассылка делалась дольше, но почтовый сервис при этом не вставал колом, а работал в штатном режиме.

Кстати, в Exim по моему есть параметры, регулирующие процесс доставки исходя из load average.

да, в exim можно при соблюдении определённых условий сделать режим доставки данного письма queue only, то есть отложить его доставку локальным юзерам до следующего времени разгребания очереди. и количество queue runners ограничить.

Там есть даже больше :) Посмотрите на deliver_queue_load_max:

When this option is set, a queue run is abandoned if the system load average becomes greater than the value of the option. The option has no effect on ancient operating systems on which Exim cannot determine the load average. See also queue_only_load and smtp_load_reserve.

при больших нагрузках на доставку надо переходить на lmtp транспорт вместо пайпа. У вас по умолчанию запускаются до 100 пайп процессов /usr/libexec/dovecot/deliver которые конкурентно долбятся в ящики.

нужно, чтобы доставку в ящики делали lmtp процессы, которые постоянно загружены в памяти и равномерно раскладывают почту по ящикам, исключая такие взрывы нагрузки, как в случае с пайпами. и расчитать их количество для данной системы.

https://wiki.dovecot.org/LMTP https://wiki.dovecot.org/HowTo/PostfixDovecotLMTP

пробуем, например, с 50 конкурентными lmtp процессами

dovecot:

service lmtp {
  process_min_avail = 50
}

lmtp      unix  -       -       n       -       50      lmtp

добавлю к вышесказанному еще оптимизации

virtual_transport=lmtp:unix:private/dovecot-lmtp
lmtp_destination_concurrency_limit = 10
lmtp_destination_recipient_limit = 1

доставлять по 1 респипиенту на lmtp процесс. до 10 параллелных процессов в 1 ящик.

Он же сформирует стопятьсот одинаковых писем для всего списка рассылки и начнет их доставлять конкретным пользователям, чем уже сформирует нехилую нагрузку...

Нет, у автора темы в качестве локального агента доставки (mda) используется Dovecot.

Я не хотел влезать в эту тему. Но вдруг он(iRedMail) правда создает эти 600+ процессов на каждый ящик? Это конечно пальцем в небо. Но ТС написал что так у него и есть. Насколько «мне рассказывали» dovecot при локальной доставке из каробки создает хардликки для варианта maildir. Что у ТС мы не знаем.
PS Конечно такая нагрузка, при таком малом объеме конечно смущает. Что-то странное.

если никто не увеличивал дефолтные значения, то лимит - 100 пайпов доставки.

Ну так вообще не о чем на гигабитном интерфейсе.
Смотрите: «письмо» «один штука», мы его прогнали через всякие sa, clamav и т.п. отдали в mda, mda уже разложит по получателям, если их хоть 1000 в случае maildir просто создаст хард линки. Откуда столько процессов, не понятно.

нет никаких хардинков в maildir. файл-письмо уникальное в каждом maildir. заголовки разные.

нет никаких хардинков в maildir. файл-письмо уникальное в каждом maildir. заголовки разные.

Да ладно? С чего бы это они разные если это рассылка?

hardlinkи используются при копировании файлов внутри maildir например, из new/ в cur/ и т.д.

в каждом письме у получателя свой delivered-to:, последний received: от lda или lmtp со своим id и timestamp. это даже если рассылка на postfix alias.

Стоп! Вы что-то путаете похоже. Приходит рассылка, неважно откуда, хоть извне. Письмо полностью идентично для каждого получателя. Или вы про варианты bcc ? Тогда согласен.

я не путаю, я смотрю файлы в Maildir :) Они разные.

Путаете. Для примера на небольшом почтовике прямо сейчас.
du -hs
212G
du -hsl
280G
Разница очевидна.
ЗЫ Прошу прощения, не пояснил, это не dovecot, а cirus, но про dovecot говорили тоже самое, что из каробки так же использует хардлинки при возможности.

если их хоть 1000 в случае maildir просто создаст хард линки.

Я думаю, этот момент ключевым является. Скорее всего, у автора темы почтовые ящики в формате mbox со всеми вытекающими... Собственно говоря, поэтому выше ему и посоветовали разобраться с Dovecot.

Скорее всего, у автора темы почтовые ящики в формате mbox со всеми вытекающими...

Согласен. Или в БД лежат, без дедупликации.

у cirus не maildir а свои db в каждом боксе. maildir формат хранит все письмо целиком в файле. и эти файлы различаются в разных боксах.

тут все пытаются накинуть какие-то дедупликации, хардлинки и прочее. Довекот имеет свои mdbox, sdbox дб форматы ящиков с такими возможностями. НО. iredmail, насколько видно из документации, использует обычный maildir. никаких харлинков между ящиками тут быть не может. файлы различные. из документации довекот:

maildir_copy_with_hardlinks=yes (default): When copying a message, do it with hard links whenever possible. This makes the performance much better, and it's unlikely to have any side effects. Only reason to disable this is if you're using a filesystem where hard links are slow (e.g. HFS+).

хардлинки используются при копировании файлов. это происходит только внутри maildir.

при всей скудности Maildir оно имеет много плюсов использования. прозрачность бекапирования, легкость переноса ящиков между бекендами, миграции и проч. грубо говоря, maildir ящик самодостаточен и не зависит от общих db файлов.

у cirus не maildir а свои db в каждом боксе

Не надо писать то о чем вы не знаете!!! Письма лежат отдельно, каждый в своем файле. То что вы назвали db это только индекс, отдельный файл, да, с содержанием всяких отдельных аттрибутов, но это ни имеет отношение к хардлинкам.
Мухи отдельно, хардлинки отдельно. Если удалить индексные файлы, то вы потеряете атрибуты, вида «прочитано/не прочитано/и другие которые можно установить по imap, но не сами письма» И можно запустить переиндексацию.

я в курсе про индексы, я про них даже не писал. На вскидку https://cyrusimap.org/imap/concepts/deployment/databases.html

у cyrus imap нет maildir формата. скорее всего у вас lmdb. сравнивать с maildir нет смысла.

Implemented single-instance store: deliver, when using LMTP, will only store one copy of a message per partition, and hard link it among multiple users. Sites with a large number of partitions could see a performance decrease.

у cyrus imap нет maildir формата

Опа папа. У меня цирус фиг его знает сколько лет работает в maildir. На многих серверах. ЧЯДНТ? Про использование индексов я вам выше уже написал. Это и не смертельно и нет. Зависит от пользователей.

https://ru.wikipedia.org/wiki/Maildir

найди здесь слово cyrus

Таки мне пофиг, вот верите нет? Я на цирусе и «убийцу» запускал, даже какое-то время проработало (потом стало не нужно), прикольная штука, только вот «письма» в его текстовом изложении так и остаются оригинальными и хардлинками так и остаются. Не надо тут приводить какие-то из головы изложения с изменяемыми заголовками плиз. Вот серьезно. Человек который никогда даже не использовал то о чем пишет, быстро гуглит и приводит «косвенные примеры». FYI цирус «славиться» «проблемой» очень плохая документация в отличии от других mda. И если вы даже не пробовали его «готовить» не надо даже ссылаться на документацию. Приготовление цируса большой труд, конечный итог конечно стоит того, но это не давкот который по первому мануалу можно приготовить.

у меня был cyrus на 7000 ящиков 10 лет назад. сейчас я эксплуатирую dovecot с maildir. я в курсе потерь общих аттачментов и рассылок. и прочих прелестей дедупликейшена и хардлинков. dovecot конечно на другом предприятии. тут тоже все плохо при горизонтальном масштабированиии при работе с nfs. Я в курсе что такое индексы и как их выносить на другие стореджи и как оптимизировать fs стореджей боксов и индексов. Я дал хороший совет топик стартеру. Я проработал это и надеюсь другим пригодится.

10 лет назад вы врядли знали что такое «убийца». (специально на русском написал это название) А так же глубоко не копали цирус с репликой.
Поверьте, цирус умеет столько всего «волшебного», что «„коту“ и не снилось». Но у него(цируса) есть проблемы другого плана, совместимость версий и т.д. Это да. Может принести много неприятностей, если у вас много «собранных вместе серверов».
PS И вот не надо говорить что цирус изменяет заголовки в maildir, он не менял 10 лет назад и сейчас не меняет.

именно поэтому яндекс работает на довекоте, а не цирусе...

В файле /etc/dovecot/conf.d/10-mail.conf данный параметр по умолчанию выключен. После включения и перезагрузки сервиса Dovecot, рассылки размером 30мб+ уходят моментально, нагрузка возрастает только на процессор.

Спасибо, Ваш способ помог решить мою проблему.