Оптимизация работы и использования системных ресурсов

Контроль пулов потоков:

Поскольку модули Dr.Web MailD используют многопоточную модель при получении, обработке и доставке сообщений, то каждый из модулей по мере необходимости создает определенное количество потоков обработки. Чем больше объем обрабатываемого почтового трафика и чем больше проверок сообщений надо выполнить компонентам (например, проверка для письма большого набора Правил обработки, сканирование содержимого писем антивирусным модулем Drweb в режиме «paranoid»), тем большее количество потоков будет создавать каждый компонент. Все потоки, создаваемые компонентами, организованы в пулы потоков. Поведение потоков в пулах регулируется параметрами типа PoolOptions. Эти параметры также указывают для каждого пула количество потоков в нем (как минимальное t_min, так и максимальное t_max). По умолчанию для всех пулов потоков всех модулей Dr.Web MailD задано значение auto.

Ограничение количества потоков в пуле модуля drweb-receiver не только не позволяет ему создавать новых активных потоков сверх разрешенного количества, но и также влияет на его поведение в ходе SMTP-сессий. Если число подключений со стороны клиентов больше, чем разрешено иметь потоков в пуле, то модуль drweb-receiver создает максимально разрешенное число активных потоков, а остальные соединения, для которых поток-обработчик уже нельзя создать, помещаются в очередь ожидания. Как только любой из активных потоков-обработчиков освобождается, то он сразу начинает обрабатывать очередное соединение из этой очереди. Поскольку обработка соединений идет асинхронно, то один и тот же активный поток может обрабатывать по нескольку соединений одновременно. Длина очереди клиентских соединений также всегда ограничена максимально разрешенным числом потоков в пуле drweb-receiver. Таким образом, одновременно drweb-receiver может «удержать» не более, чем 2*t_max соединений, при этом часть из них может находиться в очереди ожидания. Как только очередь ожидания будет заполнена, то drweb-receiver прекращает прием новых соединений и отвечает клиентам ошибкой вида:

Server error: 421 3.8 Too many concurrent SMTP connections; please try again later

При больших нагрузках некоторая часть новых соединений в этом случае все же будет обрабатываться, так как освобождающиеся активные потоки компонента сразу будут забирать соединения из очереди ожидания и освобождать место для новых, но в целом в этом случае следует попробовать увеличивать верхнюю границу t_max количества потоков в пуле модуля drweb-receiver, чтобы избежать отказа в обслуживании новых подключений. Для остальных модулей Dr.Web MailD увеличение числа потоков в пулах на функциональном поведении не сказывается.

Чтобы контролировать состояние компонентов (количество активных потоков в пулах и длины очередей), рекомендуется периодически отправлять всем процессам Dr.Web MailD сигнал SIGUSR1.

Когда компоненты Dr.Web MailD получают сигнал SIGUSR1, они производят сброс статистики по пулам потоков. Сброс статистики производится как в отдельные текстовые файлы, так и в виде записей в журнал (на уровне подробности Debug). Местоположение файлов статистики регулируется параметром BaseDir в секции [General]). Подробнее о форматах статистики см. в разделе Внутренняя статистика работы.

Статистика пулов потоков модулей drweb-sender и drweb-receiver сохраняется в файлах sender_thr.txt и receiver_thr.txt соответственно. Статистическая информация содержит данные о текущем размере пула, число активных потоков, и соединений, находящихся в очереди. Максимально разрешенное количество потоков в пуле t_max следует увеличивать, когда число соединений, находящихся в очереди (pending) приближается к числу активных потоков (active).

Увеличивать числа потоков в пулах надо с осторожностью. Для этого требуется предварительно оценить:

•Объем потребляемой памяти;

•Количество открываемых файлов и сокетов (т.е. файловых дескрипторов);

•Мощность CPU.

Чем больше для пулов значение t_min (минимальное количество потоков в пуле), тем больше времени требуется компонентам Dr.Web MailD для запуска и установки начальных соединений. Например, если используется антивирусный модуль Drweb, то потоки из его пула потоков при запуске создают соединения с антивирусным сканером Dr.Web Daemon, в следствие чего удлиняется время запуска компонента MailD core. Если минимальное число потоков в пуле потоков некоторого компонента слишком велико, то при старте он может не успеть запуститься за период тайм-аута StartTimeout, указанного в его настройках запуска у управляющего компонента Dr.Web Monitor. В этом случае Dr.Web Monitor аварийно завершит работу как этого компонента, так и всего комплекса Dr.Web MailD при старте.

Аналогично, если для пулов некоторого компонента указано большое число t_max (максимальное количество потоков в пуле), то могут возникать уже проблемы при завершении работы комплекса Dr.Web MailD, когда его компоненты не будут успевать завершать свою работу за отведенный на это тайм-аут, и в этом случае работа всего комплекса также будет завершаться управляющим компонентом Dr.Web Monitor аварийно.

Поэтому не следует увеличивать количество создаваемых потоков "про запас", так как, когда это число достаточно велико (порядка 1000 для модулей drweb-receiver и drweb-sender и порядка 2000 – для всех остальных модулей), возможно возникновение задержек в при создании новых потоков и появление ошибок, связанных с истечением тайм-аутов для потоков непосредственно при обработке писем, что приводит к ошибкам обработки и даже может повлечь потерю писем. В случае если это происходит, число потоков следует уменьшать. Если все же невозможно уменьшить количество используемых потоков, то необходимо:

1)Увеличить величину тайм-аута подсистемы IPC (регулируется параметром IpcTimeout в секции [General]), например до 10 минут;

2)Увеличить максимально разрешенное время ожидания закрытия одного потока, которое используется при перезапуске и при завершении работы Dr.Web MailD (регулируется параметром MaxTimeoutForThreadActivity в секции [General]), например до 3 минут;

3)Увеличить тайм-ауты ожидания запуска (StartTimeout) и завершения работы (StopTimeout) компонентов Dr.Web MailD в управляющем файле maild_<mta>.mmc монитора Dr.Web Monitor (так как большему количеству потоков требуется большее количество времени на остановку).

Также в этом случае крайне желательно провести более тонкую настройку всего комплекса в целом (см. ниже).

Возможные симптомы, указывающие на исчерпание системных ресурсов:

1)Может возникнуть ситуация, когда очередной поток в некотором пуле не может быть создан, что приведет к фиксации в журнале (логе) соответствующего компонента ошибки следующего вида:

ERROR <some description>: boost::thread_resource_error

В этом случае следует уменьшить количество активных потоков для соответствующего пула потоков, а в случае если количество потоков в пуле выбрано автоматическим (auto), то задать явные количества потоков.

Если заданного количества потоков недостаточно, а при увеличении количества потоков происходит указанная ошибка, то следует увеличить призводительность сервера, т.е. увеличить объем оперативной памяти и процессоров (ядер), доступных Dr.Web MailD.

2)При большой нагрузке могут не приниматься к обработке сообщения, при этом Dr.Web MailD будет фиксировать в журнале сообщения вида

Too many open files

Возникновение ошибки вызвано исчерпанием количества файловых дескрипторов, доступных Dr.Web MailD (в том числе – дескрипторов сокетов).

Для ее решения необходимо (в ОС Solaris версии 10) перед запуском модуля drweb-receiver выставить переменную окружения LD_PRELOAD_32 в значение /usr/lib/extendedFILE.so.1. Это действие можно выполнить:

•Непосредственно в консоли, если drweb-receiver запускается не через стартовый скрипт, а из консоли;

•"Завернув" запуск drweb-receiver в скрипт-обертку, выполняющий перед запуском модуля задание нужного значения этой переменной окружения;

•Изменив стартовый скрипт для drweb-monitor (/etc/init.d/drweb-monitor), добавив в него соответствующие строки установки значения системной переменной окружения.

Обратите внимание, что в последнем случае переменная окружения будет выставлена не только для drweb-receiver, но и для всех процессов Dr.Web, запускаемых через Dr.Web Monitor.

Если проблема все равно осталась, то, оставив все отписанные выше изменения, необходимо:

•увеличить значения ulimit -n;

•добавить (или исправить, если они имеются) следующие строки в файле /etc/system:

set rlim_fd_max = 65335
set rlim_fd_cur = 65335

При возникновении этой ошибки в других ОС (FreeBSD и Linux) следует увеличить лимит на число файловых дескрипторов для процесса/пользователя и увеличить значения ulimit -n.

Общие рекомендации по повышению производительности и быстродействия:

Для повышения производительности и быстродействия в случае больших нагрузок желательно:

▪Использовать асинхронный режим обработки писем, то есть использовать примерно следующую расстановку подключаемых модулей по очередям:

BeforeQueueFilters = headersfilter, vaderetro
AfterQueueFilters = drweb, modifer

▪Увеличить тайм-ауты:

oПодсистемы IPC (регулируется параметром IpcTimeout в секции [General]);

oМаксимально разрешенное время ожидания закрытия одного потока, которое используется при перезапуске и при завершении работы Dr.Web MailD (регулируется параметром MaxTimeoutForThreadActivity в секции [General]);

oВремя ожидания запуска и завершения работы компонентов Dr.Web MailD в управляющем файле maild_<mta>.mmc монитора Dr.Web Monitor.

▪Увеличить величины ulimit -n.

▪Проанализировать загрузку пулов потоков путем сбора статистики (см. выше), если это необходимо, изменить граничные значения для соответствующих пулов потоков.

▪Выполнить монтирование каталогов %var_dir/msgs и %var_dir/infected в файловую систему tmpfs (командой mount -t tmpfs tmpfs <directory>, где <directory> – монтируемый каталог).

▪Во всех параметрах, использующих Lookup, использовать Lookup к файлам (file:, rfile:), регулярным выражениям (regex:) или простые списки (так как обращение к внешним СУБД и LDAP при обработке каждого письма резко снижает скорость обработки, кроме того, успешность обработки ставится в зависимость от стабильности подключения к СУБД или серверу LDAP).

▪Установить значение параметра MoveAll в секции [Quarantine] в значение No (особенно если %var_dir/msgs и %var_dir/infected не смонтированы в tmpfs).

▪Установить значение параметра SyncMode в секции [MailBase] в значение No.

▪Увеличить объем памяти, используемой внутренней БД, для чего увеличить значение параметра MaxPoolSize в секции [MailBase], что уменьшит количество обращений к диску.

▪Отключить использование статистики и отчетов (установив значения параметров Detail=off и Send=no в секции [Stat] и секции[Reports] соответственно).

▪Настроить вывод всех журналов в файлы вместо syslog.

▪В параметрах ProtectedNetworks и ProtectedDomains в секции [Maild] защищаемые сети и домены перечислить списком (см. выше замечание о рекомендуемом использовании Lookup).

▪Если нет Правил обработки писем, использующих условия, содержащие поле client-ip, то установить значение параметра GetIpFromReceivedHeader в секции [Maild] в значение No.

▪Установить значение параметров: SkipDSNOnBlock = Yes (в секции [Maild]), SendSDN = No (в секции [Sender]), а в настройках действий подключаемых модулей стараться избегать использования опциональных действий notify и redirect.

▪Отключить использование Карантина (убрать действие quarantine для подключаемых модулей, если оно задано как одно из действий).

▪Ограничить максимальный размер сообщений, проверяемых подключаемыми модулями (задав значения параметров MaxSizeBeforeQueueFilters и MaxSizeAfterQueueFilters в секции [Filters]).

▪Значения параметров StalledProcessingInterval в секции [Sender] и секции [Receiver] не должны быть меньше значений, заданных по умолчанию (10m).

Если в процессе работы Dr.Web MailD наблюдаются задержки при отправке сообщений и растет число соединений  в очереди пула потоков модуля drweb-sender, то следует, в зависимости от настроенного метода доставки (указано в значении параметра Method в секции [Sender]), выполнить следующую регулировку:

▪Для метода доставки SMTP:

oУменьшить величину тайм-аута OtherCmdsTimeout в секции [Sender].

oЕсли используется настройка Router в секции [Sender], постараться не использовать в этом параметре Lookup, обращающихся ко внешним СУБД и LDAP (см. выше замечание о рекомендуемом использовании Lookup).

oПроверить работу MTA, принимающих исходящие от Dr.Web MailD письма – как быстро от них приходит ответ при попытке модуля drweb-sender соединиться, нет ли ошибок при доставке сообщений.

▪Для метода доставки Pipe:

oПроверить работу локального MTA, принимающего исходящие от Dr.Web MailD письма. Его демон, отвечающий за локальную доставку сообщений, должен быть настроен корректно.

Если в процессе работы Dr.Web MailD растет очередь сообщений, ожидающих доставки (располагается в каталоге %var/msgs/out), то рекомендуется попробовать отправить модулю drweb-sender сигнал SIGUSR2 в часы непиковых нагрузкок.

Кроме того, вы можете построить кластерное решение, воспользовавшись внутренним проксированием запросов от компонентов Sender и Receiver к нескольким экземплярам компонента MailD core.

Рекомендации по настройке Dr.Web MailD в случае преобладания в обрабатываемом трафике писем большого размера:

1.Рекомендуется воздержаться от использования подключаемого модуля Dr.Web Modifier и вообще от любой фильтрации на основе анализа контента (т.е. это и использование настроек RejectPartCondition, AcceptPartCondition, MissingHeader у подключаемого модуля Dr.Web HeadersFilter; настройки RegexForChechecked у подключаемого модуля Drweb и т.д.), т.к. если поиск будет вестись именно внутри вложенных MIME-объектов, это сильно замедлит обработку писем. Подключаемые модули Vaderetro, Dr.Web Modifier и Drweb хранят и тело письма и заголовки при обработке в оперативной памяти, поэтому желательно поместить их в очередь AfterQueueFilters (использовать асинхронный режим).

2.Увеличить тай-маут IPC (IpcTimeout в секции [General]) до 5 минут, если используется подключаемый модуль Drweb.

3.Увеличить таймаут на сканирование файлов в настройках Dr.Web Daemon, а также Timeout в настройках подключаемого модуля Drweb (максимум – 10 минут).

4.Смонтировать каталоги писем и Карантина (%var_dir/msgs и %var_dir/infected) в файловую систему tmpfs, но только в том случае, если имеется достаточный объем оперативной памяти, т.к. письма имеют большой объем.

5.Указать максимальный размер тела письма, сохраняемого во внутренней БД, в 1 Кб (установить MaxBodySizeInDB = 1k в секции [MailBase]).

6.Снять ограничения по объему писем в Карантине и объему диска, выделенному под Карантин (установить в 0 значения параметров MaxSize и MaxNumber в секции [Quarantine]). Обратите внимание, что если используется DBI, и Карантин с большими письмами будет сохраняться в СУБД, то это также вызовет дополнительную нагрузку на сервер, что напрямую не отразится на работе Dr.Web MailD, но отразится на величине средней загрузки сервера.

7.Время хранения писем в Карантине, если особых условий не требуется, лучше сократить (регулируется параметром StoredTime в секции [Quarantine]), чтобы они не накапливались и не занимали места.

8.Контролировать объем каталогов %var_dir/msgs/out и %var_dir/msgs/out/failed, чтобы сразу отслеживать проблемы с доставкой писем для доменов и не забивать жесткий диск.

Для стабильной работы Dr.Web MailD необходимо иметь запас оперативной памяти, больший, чем суммарный объем писем за секунду, умноженный среднее время обработки письма в секундах. При этом ограничение числа потоков в настройках пулов потоков компонентов ограничивает суммарный объем писем, обрабатываемых за секунду. Среднее время обработки письма в секундах зависит только от мощности сервера (при фиксированных настройках для подключаемых модулей, Правил обработки и т.п.), поэтому для его необходимо измерять по журналам Dr.Web MailD конкретно для текущей архитектуры. Для стабильности число потоков в пулах потоков модулей drweb-receiver (drweb-milter), drweb-maild и drweb-sender должны быть одинаковыми. Однако, если drweb-sender использует маршрутизацию, заданную параметром Router, у него должно быть больше потоков в пуле, чем у других компонентов.

В случае если будут наблюдаться нехватки времени на обработку писем при установленном в 5 минут IpcTimeout, следует выполнить балансировку нагрузки и уменьшать число потоков в пулах компонентов (см. выше).