|
|
Hello,
On 20.11.2016 0:28, Subscriber wrote:
On Sat, 19 Nov 2016 19:34:25 +0300 "Roman Prokhorov"
<CGatePro@ru.stalker.com> wrote:
Hello, On 02.11.2016 15:46, Subscriber wrote:
Roman Prokhorov пишет:
Здравствуйте,
У нас уже есть готовое решение:
<http://www.communigate.com/CGPJournaler/russian.html>
Требуется CGPro 6.0 или новее.
Здравствуйте!
Извините, упустил это письмо в листе...
Отличная штука , работает.
Но есть некоторые проблемы : - при большом потоке письма не
успевают сохранятся в выделенный ящик и очередь начинает расти ,
и за пару часов доходит до нескольких тысяч , хотя диск не
очень-то и загружен. вопрос : можно-ли как-то распараллелить
сохранение этих писем через несколько процессов LOCAL , а не
через один как сейчас?
В один экаунт пишет только один процесс LOCAL. Так что можно
сделать несколько журналов, чтобы письма пользователей от A до H
шли в один, от I до N во второй, и т.д.
До этого тоже догадался , попробовал - помогло , но пришлось
отказаться от деления пользователей по буквам из-за другой проблемы
- выяснилось , т.к. многие пишут письмо сразу разным адресатам , то
письма одни и те-же повторяются в разных журналах и общий объем
хранения сильно возрастает.
Но вообще большая очередь не должна быть проблемой: за день она
разрастётся, а за ночь всё равно рассосётся; при том что задержка
при записи в журнал некритична.
Ага , рассасывалось ночью . Сейчас решили проблему по скорости работы
этого сетевого диска по NFS и пока письма успевают сохранятся.
То есть всё упиралось в скорость диска, а не процессора LOCAL?
И желательно для журнального домена выделить отдельный диск, чтобы
запись в журнал никак не сказывалась на доставке почты другим
пользователям.
Отдельный диск , но был случай ,когда связь с диском надолго (до часу
из-за проблем сетевого оборудования) прервалась , то и встала вся
очередь всех писем . Оказалось , что сбойнул сам хелпер , т.к. он
периодически считывает настройки аккаунта журнала , а они на диске ,
который и недоступен. И в итоге работа серверных правил не
завершалась - письма пользователей принимались , но оставались в
очереди.
Проблемы с доступностью дисков быть не должно. Если это сетевой диск - её надо предотвращать использованием отказоустойчивых контроллеров и т.п. А вообще, если у вас не кластер, то нет особого смысла хранить данные на сетевом диске - если накроется серверная машина, то внутренние диски из неё можно перенести в новую.
- если пользователи отправляли письма многим адресатам , то
результирующее письмо сохраняется со слишком большим по размеру
заголовком ( из-за множества полей X-rcpt: ) и после
восстановления таких писем , клиенты их не могут прочитать :(
Это решаемо, но надо будет переделать скрипт восстановления, чтобы
он не просто копировал найденные письма средствами сервера, а сам
зачитвал их, удалял служебные заголовки, и сам записывал.
Спасибо Роман , примерно подход к восстановлению понятен.
Есть вопросы по использованию журнала на больших инсталяциях. Какой у вас объём журнала и сколько времени занимает восстановление? Свяжитесь со мной через support@communigate.com
--
Roman
|
|