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

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

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

Допущения

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

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

См. также

Что дальше

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

Наверх