Перейти к основному контенту

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

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

Допущения

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

Параметр Значение Комментарий
Средний размер письма ~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 ТБ под накопление — это верхняя граница режима. При включённом распознавании текста или дальнейшем росте разделяйте роли по отдельным узлам.

См. также

Наверх