Расчёт мощностей

Эта страница поможет подобрать сервер для установки «всё в одном» под ожидаемый объём архива. Цифры ориентировочные — реальное потребление зависит от характера переписки и включённых функций. Закладывайте запас.

Допущения

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

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

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

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

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

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

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

Цифры приведены для среднего размера письма ~200 КБ. Если переписка тяжелее (например, архивируете ящики бухгалтерии или юристов с большим числом сканов и PDF), умножайте дисковые значения на 1,5–2. Если легче (поток SMTP без вложений) — на 0,3–0,5.

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

Конвейер импорта: получение письма → извлечение текста вложений (Tika) → запись в хранилище с проверкой дедупликации → индексация (Solr) → вставка метаданных (PostgreSQL). Один узел устойчиво обрабатывает 15–30 писем в секунду без OCR.

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

Вывод: вычислительной мощности для устойчивого импорта хватает на всех трёх объёмах на одном узле. Поступление писем много ниже возможностей узла.

Рекомендации по железу (всё в одном)

Объём в месяц	RAM	vCPU	Быстрый диск (система, БД, индекс)	Диск хранилища (1 год / 5 лет)
100 тыс.	8 ГБ	4	100 ГБ SSD	250 ГБ / 1 ТБ
500 тыс.	16 ГБ	6–8	200 ГБ SSD	1 ТБ / 5 ТБ
1 млн	32 ГБ	8–12	300 ГБ SSD	2 ТБ / 10 ТБ

Почему столько памяти

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 млн писем сразу) идёт тем же конвейером: при 20 письмах в секунду — около 3 суток. Это нормальное поведение, но в это время узел загружен, и поиск или IMAP могут работать медленнее.

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

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

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

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

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

См. также

Введение и требования — краткие системные требования, роли узла

Установка — способы установки

Хранилища и группы хранилищ — избыточность и шифрование

Обслуживание → Кластер и узлы — масштабирование