Расчёт ресурсов и сайзинг

Перед началом

{{ССЫЛКА:install.system-requirements|Системные требования}}

Допущения

Расчёт построен на типичных значениях корпоративной почты. Если ваш профиль сильно отличается — пересчитайте по фактическим данным.

Параметр	Значение	Комментарий
Средний размер письма	~200 КБ	тело + вложения с учётом тяжёлых писем (сканы, презентации). Большинство писем лёгкие (~50 КБ), но тяжёлые тянут среднее вверх
Доля писем с вложениями	~25 %	не у каждого письма есть вложение
Дедупликация вложений	~25 % экономии	один и тот же файл (регламент, прайс, рассылка) встречается у многих получателей
Распознавание текста (OCR)	выключено	отдельный сценарий ниже — при включении требования к CPU возрастают
Срок хранения	5 лет	накопленный объём

Ресурсы на одно письмо (накопление)

Компонент	На письмо	Откуда
Хранилище (после дедупликации)	~150 КБ	тело и вложения минус дедупликация, плюс служебные данные
Поисковый индекс (Solr)	~15 КБ	текст темы, тела и вложений, технические поля
База данных (PostgreSQL)	~8 КБ	метаданные письма, адреса, папки, вложения, индексы

Накопленный объём

Объём растёт линейно и зависит от срока хранения. Ниже — суммарный объём по компонентам.

Писем в месяц	Писем в год	Хранилище	Поисковый индекс	База данных	Хранилище (5 лет)
100 тыс.	1,2 млн	180 ГБ	18 ГБ	10 ГБ	900 ГБ
500 тыс.	6 млн	900 ГБ	90 ГБ	50 ГБ	4,5 ТБ
1 млн	12 млн	1,8 ТБ	180 ГБ	100 ГБ	9 ТБ

Пропускная способность импорта

Конвейер импорта: получение письма → извлечение текста вложений → запись в хранилище с проверкой дедупликации → индексация для поиска → сохранение метаданных.

Один узел в режиме "всё-в-одном" без OCR устойчиво обрабатывает 10-30 писем в секунду при допустимых пиках до 100–150 писем/сек. Для примера:

Объём в месяц	В день	Средний темп	Пиковый темп
100 тыс.	~3 300	0,04/с	~0,4/с
500 тыс.	~16 700	0,2/с	~2/с
1 млн	~33 300	0,4/с	~4/с
70 млн	~2.3 млн	30/с	300/с

Использование памяти

PostgreSQL — около 25 % RAM под shared_buffers, а также пул соединений и рабочая память. При накоплении от 1 млн писем — 8 ГБ минимум.

Solr — heap(!) 4–8 ГБ достаточно для 180 ГБ индекса: память хранит поисковые структуры и кеши, а не весь индекс. Месячное шардирование и выгрузка холодных бакетов экономят heap(!).

Узел Клавдия (веб-интерфейс, импорт, индексация, хранилище) — 1–2 ГБ.

Операционная система и Docker — 1–2 ГБ.

Нагрузка на процессор

Извлечение текста вложений (Tika) — процессороёмкая операция. 2–4 ядра покрывают 100–500 тыс. писем в месяц, 8–12 ядер — для 1 млн писем в месяц с запасом под пики и одновременный поиск.

Поиск и IMAP дополнительно нагружают процессор при активных запросах пользователей.

Диск — два пула

Быстрый SSD (случайный ввод-вывод) — система, база данных, поисковый индекс. Случайные чтения и записи требуют SSD.

Хранилище писем — блоки писем пишутся последовательно, читаются при просмотре. Подойдёт более медленный диск или NFS, но SSD лучше для быстрых проверок дедупликации. Объём растёт линейно с накоплением — закладывайте под срок хранения.

Распознавание текста (OCR) — отдельный сценарий

Если включено распознавание текста во вложениях (tesseract для графических файлов), обработка одного изображения на ядре процессора занимает 1–5 секунд. При доле изображений 10 %:

100 тыс. в месяц — узел справится, но индексация будет отставать.

500 тыс. в месяц — нужен отдельный узел с ролью indexer (или дополнительные 4–8 ядер только под распознавание).

1 млн в месяц — обязательно вынос индексации и распознавания на отдельный узел или несколько узлов.

При включённом распознавании текста рекомендации по процессору для 500 тыс. и 1 млн удваивайте.

Массовый первоначальный импорт

Описанные объёмы — это устойчивый приток новых писем. Первоначальный импорт существующего архива (например, 5 млн писем сразу) идёт тем же конвейером, узлы импорта и хранения могут быть загружены до 100%, отчего поиск или IMAP могут работать медленнее.

Рекомендуется выделить под письма старше Х лет отдельные тома хранилища и маршрут сохранения.

Когда уходить с «всё в одном»

Триггер	Что делать
1 млн в месяц устойчиво + распознавание текста	вынести роль `indexer` на отдельный узел
Хранилище более 2 ТБ или нужна избыточность	отдельные узлы `storage` с группами (избыточность от 2)
Несколько тысяч одновременных пользователей IMAP	отдельные граничные узлы `imap`
Отказоустойчивость базы данных	PostgreSQL на отдельный сервер или кластер

Практический вывод

Установка «всё в одном» уверенно справляется с 100 тыс. и 500 тыс. писем в месяц на одном сервере (8–16 ГБ памяти, 4–8 ядер). Для 1 млн писем в месяц нужен сервер с 32 ГБ памяти, 8–12 ядрами и от 2 ТБ под накопление — это верхняя граница режима. При включённом распознавании текста или дальнейшем росте разделяйте роли по отдельным узлам.

См. также

{{ССЫЛКА:install.what-is-klvd|Введение и требования}} — краткие системные требования, роли узла

{{ССЫЛКА:install.choose-topology|Установка}} — способы установки

{{ССЫЛКА:install.storage-overview|Хранилища и группы хранилищ}} — избыточность и шифрование

{{ССЫЛКА:maintenance.cluster-status|Обслуживание → Кластер и узлы}} — масштабирование

Что дальше

{{ССЫЛКА:install.network-install|Сетевые требования для установки}}

Навигация по книге

Следующая статья: {{ССЫЛКА:install.network-install|Сетевые требования для установки}}