LINUX.ORG.RU
решено ФорумAdmin

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

 , , , ,


2

2

Есть 2 сервера.

mail-server (iRedMail). Вся почта хранится на сетевой шаре /mnt/vmail прикрученной по NFS

storage-server (NFS, на SSD)

Скорость передачи данных по сети между серверами 1 Гбит/с.

Количество пользователей почты 600+.

Проблема: При рассылке писем с вложениями(Даже если вложение меньше 1мб) нагрузка на диск доходит до 100%. Почтовый сервер уходит в «out of service». Htop показывает статус «D» у процессов Dovecot на почтовом сервере. На хранилище Atop показывает бешеную нагрузку на диск.

Как я понял, dovecot кладет вложения в папку каждого пользователя, участвующего в рассылке и из-за этого такая нагрузка на диск.

Вопрос: Сталкивался ли кто с таким? И что в таких ситуациях делать.

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

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

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

ados ★★★★★ ()
Последнее исправление: ados (всего исправлений: 1)
Ответ на: комментарий от ados

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

dari0n ()
Ответ на: комментарий от dari0n

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

VinilNavigator ()

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

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

Serge10 ★★★★★ ()

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

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

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

Bers666 ★★★★★ ()
Ответ на: комментарий от Serge10

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

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

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

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

dari0n ()
Ответ на: комментарий от dari0n

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

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

Serge10 ★★★★★ ()

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

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

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

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

VitalkaDrug ★★ ()
Ответ на: комментарий от VitalkaDrug

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

Bers666 ★★★★★ ()
Ответ на: комментарий от Bers666

Там есть даже больше :) Посмотрите на 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.

VitalkaDrug ★★ ()

при больших нагрузках на доставку надо переходить на 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
}
postfix master.cf
lmtp      unix  -       -       n       -       50      lmtp

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от VitalkaDrug

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от Serge10

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

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

Serge10 ★★★★★ ()
Ответ на: комментарий от anonymous

тут все пытаются накинуть какие-то дедупликации, хардлинки и прочее. Довекот имеет свои 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 файлов.

anonymous ()
Ответ на: комментарий от anonymous

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 3)
Ответ на: комментарий от anc

я в курсе про индексы, я про них даже не писал. На вскидку 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.

anonymous ()
Ответ на: комментарий от anonymous

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

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

anonymous ()
Ответ на: комментарий от anonymous

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

dari0n ()