Сервер для системы электронного документооборота: запас RAM и дисков

С чего начинается проблема с производительностью СЭД

Первые жалобы на СЭД почти всегда одинаковые: медленно открываются карточки, поиск «думает», вложения скачиваются с задержкой, а отчеты или выгрузки иногда падают по таймауту. Это легко списать на «плохой интернет» или «неудачную версию», хотя причина часто проще: сервер перестал справляться с реальной нагрузкой.

Почему первые месяцы все обычно работает нормально, а потом система начинает «плыть»? В начале мало документов, индексы небольшие, а рабочие данные хорошо помещаются в кэш. Со временем растет архив, увеличивается число карточек и связей, усложняются права доступа и маршруты согласования. Сервер начинает упираться не в «паспортные» характеристики, а в конкретные узкие места: задержки дисков, нехватку RAM под кэш, очереди на индексацию.

Смотреть стоит не на красивые цифры в прайсе, а на метрики, которые показывают, где именно теряется время. Самые полезные:

• p95 или p99 времени отклика (среднее часто маскирует проблему)
• задержка диска (latency) и очередь на запись/чтение
• использование RAM и наличие свопа
• IOPS и пропускная способность хранилища в часы пик
• фоновые задачи (индексация, бэкапы, регламентные отчеты) и время их запуска

Важно разделять нагрузку от пользователей и нагрузку от «невидимой» части системы. Пользователи создают пики: массовое согласование утром, поиск перед совещанием, загрузка вложений в конце дня. Индексация и пересчет служебных данных дают более ровную, но тяжелую фоновую нагрузку. Она способна забрать диски и память даже ночью, а при росте архива постепенно «заходит» и в рабочее время.

На практике все часто выглядит так: по CPU сервер еще «свободный», но диски уже не успевают обслуживать одновременный поиск, открытие карточек и запись новых документов. Из-за этого СЭД замедляется рывками.

Какие входные данные собрать перед расчетом

Точный расчет начинается не с выбора сервера, а с цифр. Если опираться на «у нас примерно 500 пользователей», почти всегда получается перекос: CPU и RAM с запасом, но дисков не хватает, или места много, а поиск все равно тормозит.

Сначала уточните разницу между общим числом учетных записей и реальной одновременной нагрузкой. Для СЭД важнее не «сколько людей в компании», а сколько из них работает параллельно в часы пик (например, утром и перед дедлайнами). Полезно также понимать долю «тяжелых» ролей: секретариат, архив, бухгалтерия, юристы. У них обычно больше операций и вложений.

Дальше соберите данные по документам. Важны не только файлы, но и вложения: сканы, PDF, таблицы, переписка. Уточните, сколько документов создается и загружается в год, и какой средний размер вложений. Если средний размер неизвестен, сделайте срез по 200-500 последним документам по типам и посчитайте среднее и 90-й процентиль. Именно «тяжелый хвост» часто определяет рост дисков.

Минимальный набор, который стоит зафиксировать:

• пиковое число одновременных сессий и типовые действия пользователей
• прирост документов и вложений в год, включая разброс размеров
• срок хранения и правила: что удаляется, что уходит в архив, что хранится 5-10 лет
• какие операции должны быть быстрыми: поиск, согласование, массовые загрузки/выгрузки
• требования по доступности: допустим ли простой на обслуживание и какой максимум простоя

Отдельно договоритесь про архивирование. Если документы хранятся 10 лет, диски считают не «на год вперед», а на полный цикл с учетом ежегодного прироста. Важно также решить, нужно ли индексировать архив целиком или достаточно быстро открывать документы без полнотекстового поиска по старым данным.

И, наконец, проговорите доступность. Если простой недопустим (госорган, банк, крупная клиника), расчет меняется сразу: понадобится запас по ресурсам, место под резервные копии и понятный сценарий отказа. Это влияет и на итоговый выбор, когда подбирается сервер для системы электронного документооборота, а не просто «компьютер помощнее».

Память: как понять, сколько RAM нужно и где закладывать запас

RAM в СЭД расходуется не только на «саму систему». Память забирают несколько слоев: операционная система, база данных, приложение (сессии пользователей, очереди задач, кэш), а также поиск и индексация (кэш индексов, служебные процессы). Поэтому ощущение «все летает, пока пользователей мало» быстро сменяется тормозами, когда растут база и индекс.

Когда RAM не хватает, падает не только скорость. Система чаще обращается к диску, растут задержки, фоновые задачи копятся в очередях. В пике появляются таймауты, ошибки приложений и долгие перезапуски сервисов. В СЭД это особенно заметно во время массовой загрузки документов, согласований и утреннего входа пользователей.

Практичный способ прикинуть расчет оперативной памяти для СЭД - разложить потребление по ролям и заложить рост:

• ОС и служебные службы: обычно 4-8 ГБ (на Windows Server нередко больше)
• СУБД: основной потребитель (кэш данных и планов запросов)
• приложение СЭД: сессии, кэш, фоновые обработчики, конвертация файлов
• поиск и индексатор: память под индексы и кэш, которая растет вместе с количеством документов и полей

Запас по RAM нужен не «на всякий случай», а чтобы кэш работал стабильно и не сбрасывался каждые минуты. Для продакшена полезно оставлять заметную долю свободной памяти (часто 20-30%) и пересматривать расчет заранее, до того как средняя загрузка RAM приблизится к 80-90%.

Пример: сегодня 200 пользователей и 2 млн документов, через год планируете 400 пользователей и 4-5 млн документов. Даже если одновременных пользователей не так много, база и индекс вырастут почти вдвое. Значит, потребность СУБД и поиска в памяти тоже вырастет. Рост по документам стоит считать отдельно от роста по людям.

Вертикальное масштабирование (добавить RAM и CPU) разумно, когда у вас один сервер и нужно быстро снять давление на кэш СУБД или поиск. Разделять роли лучше, когда нагрузка стала смешанной: база «съедает» память, индексатор забирает свое, а приложению не хватает стабильности. Тогда отдельные узлы под СУБД и поиск дают более предсказуемую работу.

Диски: что именно растет в СЭД помимо самих документов

Когда подбирают сервер для системы электронного документооборота, часто считают только папку с файлами. Но в СЭД растут еще несколько слоев данных, и именно они неожиданно «съедают» свободное место.

Первое и самое очевидное: документы и вложения. Важен не только их счет, но и средний размер. Если сотрудники переходят со сравнительно легких PDF на сканы в высоком качестве или начинают прикладывать фото и видео, средний размер легко вырастает в 2-3 раза, даже если количество документов почти не меняется.

Второй слой: база данных. В ней живут карточки, маршруты согласования, права доступа, статусы, метаданные, а также журналы и временные файлы. Логи и temp часто растут скачками: массовая загрузка документов, закрытие периода, отчеты, обновления.

Третий слой: индексы поиска. Если включено распознавание (OCR) и индексируется весь текст, индекс может быть сравним по объему с самими документами, особенно при большом количестве сканов.

Четвертый слой: резервные копии. Место нужно не «когда-нибудь», а постоянно: под полный бэкап, цепочку инкрементальных копий, иногда под тестовое восстановление. Если бэкапы хранятся на том же хранилище, запас должен быть больше.

Чтобы не упираться в тормоза и ошибки записи, планируйте объем так, чтобы рабочие разделы не превышали 70-80% заполнения. Проверьте, заложены ли:

• рост документов и вложений по реальному среднему и «тяжелому» размеру
• отдельное место для БД: данные, журналы, временные файлы
• запас дискового пространства для архивов и индексов, включая переиндексацию
• место под бэкапы по вашей политике хранения
• постоянный буфер свободного пространства (обычно 20-30%)

Если заранее разнести эти зоны по разным дискам или массивам, проще контролировать рост и не ловить ситуацию «место есть, но критический раздел переполнен».

Типы накопителей и RAID: как не ошибиться с выбором

Даже идеально рассчитанный по объему сервер для системы электронного документооборота может тормозить, если дисковая подсистема выбрана «по гигабайтам». Для СЭД чаще важнее скорость мелких операций: сколько запросов в секунду выдерживают диски (IOPS) и какая у них задержка. Это напрямую влияет на открытие карточек, сохранение вложений и быстрый поиск.

SSD и HDD лучше разделять по задачам. SSD ставят туда, где много случайных чтений и записей: база данных, журналы, временные файлы, индексы поиска. HDD уместны там, где нагрузка более последовательная и главная цель - цена за терабайт: долгосрочный архив, редко открываемые вложения, холодные копии.

Практичный ориентир по раскладке:

• ОС и служебные роли - отдельный небольшой SSD-массив
• база данных СЭД - SSD с приоритетом низкой задержки
• индексы поиска - отдельный SSD (или SSD-массив), чтобы индексация не мешала БД
• вложения и архив - HDD-массив (или SSD, если старые документы часто открывают)
• резервные копии - отдельное хранилище, не на том же массиве, что рабочие данные

RAID нужен не только «для надежности», но и для предсказуемой работы при отказе диска:

• RAID 1 - зеркало, простое решение для небольших объемов
• RAID 10 - обычно лучший выбор для БД и индексов, но требует больше дисков
• RAID 5/6 - экономнее по объему, чаще подходит для файлов и архивов, но хуже переносит интенсивную запись

Отдельно проверьте сценарии индексации. В дни массовой загрузки документов или перестроения индексов нагрузка на диски резко растет. Если индексы лежат вместе с БД или вложениями, начнутся «просадки» по всему контуру.

Индексация и поиск: отдельный расчет под нагрузку и рост

Индексация в СЭД нужна, чтобы поиск работал быстро: система заранее строит индекс по тексту документов, метаданным, версиям и вложениям. Проблема в том, что индексация часто идет рывками и создает пики нагрузки, даже когда пользователи почти не активны.

Пики обычно возникают в двух ситуациях: массовая загрузка (скан-архив, миграция, импорт из почты) и перестроение индексов после обновлений. В эти моменты сервер может выглядеть «перегруженным», хотя в обычном режиме пользователи работали без жалоб.

Плановая индексация по расписанию (ночью, в выходные) удобна, но требует запаса ресурсов именно на это окно. Фоновая индексация распределяет нагрузку по времени, зато постоянно «съедает» часть диска, RAM и CPU и иногда делает поиск менее стабильным в часы пик.

Чтобы оценить рост индекса, смотрите не только на количество файлов, но и на содержимое:

• средний размер документа и доля «тяжелых» форматов (сканы, сложные PDF)
• процент документов с OCR
• сколько полей карточки индексируется и есть ли полнотекстовый поиск
• число версий и вложений на один документ
• сколько документов добавляется в день и сколько правится (это тоже переиндексация)

Практическое правило: держите запас по месту под индекс отдельно от архива документов и оставляйте резерв на переиндексацию после обновлений и миграций.

Где чаще всего упирается индексация: диск (много мелких операций чтения и записи), RAM (кэш и буферы), CPU (парсинг, OCR, обработка текста). Если диск медленный, индексация растягивается и мешает всем. Если RAM мало, начинается активный своп и поиск резко замедляется. Если CPU слабый, скорость индексации падает, но обычно это заметнее на больших объемах и при OCR.

Пошаговый расчет запаса по памяти и дискам

Чтобы сервер для системы электронного документооборота не уперся в ресурсы через полгода, считайте не только текущую нагрузку, но и рост.

1. Определите активных пользователей. Возьмите среднее число тех, кто работает в СЭД ежедневно, и добавьте прогноз на 2-3 года (например, +10-20% в год или рост за счет филиалов). Для запаса полезно считать два сценария: базовый и «пиковый месяц» (закрытие квартала, массовые согласования).

2. Посчитайте прирост документов и вложений. Учитывайте не только число документов, но и средний размер вложений. Удобная формула: документов в месяц x средний размер вложений x срок хранения «горячего» архива (например, 12-18 месяцев на быстрых дисках).

3. Разложите диски по категориям. Обычно место уходит в четыре части: база данных, файлы документов, индексы поиска, резервные копии. Пример: 200 ГБ в БД, 2 ТБ файлов, 300 ГБ индексов, плюс 2-3 полных бэкапа (с учетом вашей политики хранения).

4. Подберите тип накопителей и RAID под каждую часть. БД и индексы чувствительны к задержкам, им чаще подходят SSD и «быстрый» RAID. Файловое хранилище может быть на более емких дисках, если поиск и превью не завязаны на него напрямую.

После этого добавьте запас. На практике часто закладывают 30-50% по дискам на рост и пересчет индексов, и отдельный запас RAM под кэши и фоновые задачи (обычно 20-40% от получившегося значения).

Чтобы понимать, когда апгрейд уже нужен, заранее задайте триггеры:

• свободно меньше 20% на томе с БД или индексами
• индексы растут быстрее документов (признак переиндексации или новых типов файлов)
• постоянная высокая загрузка памяти и частый уход в своп
• время поиска и открытия карточек стабильно растет неделю за неделей

Типичные ошибки при подборе сервера под СЭД

Главная беда в закупках под СЭД - заложить «какой-то запас», но не понимать, где он нужен. В итоге сервер новый, а пользователи все равно жалуются на тормоза при поиске и открытии документов.

Частая ошибка - считать пользователей по численности компании. Важно не «сколько сотрудников всего», а сколько людей реально работает в СЭД одновременно в пиковые часы. Если ориентироваться на общий штат, можно переплатить. Если взять «среднее за день», можно недооценить пики и получить очереди и зависания.

Ошибки с дисками и хранением

Многие планируют только место под файлы документов и забывают о том, что растет рядом: индексы поиска, версии документов, служебные журналы, временные файлы и место под резервные копии. Еще одна типовая проблема - держать базу, индексы и файловое хранилище на одном медленном массиве. Тогда все конкурирует за один и тот же диск, и любая тяжелая операция «подвешивает» остальное.

Опасна и привычка заполнять диски почти до отказа. После 80-85% свободного места становится мало для нормальной работы индексации, обновлений и обслуживания базы. Производительность падает, а риск ошибок растет.

Невидимые «пожиратели» скорости

Антивирус и сканирование файлов часто проверяют каждый открываемый или загружаемый документ. На бумаге сервер подходит, а на практике задержки появляются именно из-за проверки. Это лучше тестировать заранее и настраивать исключения совместно с ИБ.

Короткая самопроверка перед закупкой:

• считаете пиковую одновременную нагрузку, а не общий штат
• закладываете место под индексы, версии, журналы и бэкапы
• разделяете «горячие» данные (БД и индексы) и файловое хранилище
• держите плановое заполнение дисков не выше 80-85%
• заранее замеряете влияние антивируса на типовые операции

Быстрый чеклист перед закупкой и перед запуском

Перед закупкой важно проверить не только «хватает ли ресурсов сейчас», но и есть ли понятный запас на рост пользователей, индексация документов и нагрузка на сервер в пиковые часы.

Что стоит зафиксировать в требованиях к поставке и в плане запуска:

• RAM: в рабочие часы нет постоянного свопа, а запас по памяти остается даже в пиковые моменты.
• Диски: заполнение хранилища держится ниже порога (обычно 70-80%), чтобы не упираться в падение скорости и рост времени бэкапов.
• Бэкапы: копии реально помещаются в выбранную схему хранения, а восстановление хотя бы одной типовой копии проверено по шагам и по времени.
• Индексация и поиск: индексация укладывается в выделенное окно и не забирает ресурсы так, что пользователи ждут открытия карточек и поиска.
• Мониторинг: заранее выбраны 3-5 метрик и назначен ответственный. Обычно достаточно: занятость диска, свободная RAM, наличие свопа, latency диска, время ответа СЭД или длина очереди индексации.

Перед запуском сделайте короткий тест: имитируйте типовой день (вход пользователей, загрузка документов, поиск, согласование), параллельно запустите индексацию и проверьте, не ухудшаются ли метрики.

Пример расчета на реальном сценарии (простыми числами)

Представим типовой сценарий: госорган или банк. Сейчас 600 активных пользователей СЭД, через 3 года планируют 900. Поток входящих и внутренних документов растет вместе со штатом, поэтому расчет делаем с запасом.

Исходные числа: 80 000 документов в месяц, средний размер вложений 1,5 МБ. «Горячий» период храним 36 месяцев в оперативном доступе.

Считаем хранилище: 80 000 x 1,5 МБ = 120 000 МБ, это примерно 117 ГБ в месяц. За 36 месяцев: 117 x 36 = около 4,2 ТБ только на вложения.

Но в СЭД растет не только «файл». Добавьте:

• метаданные, версии, служебные поля и логи: +30%
• индексы поиска: часто 10-20% от объема текста и метаданных, возьмем +15%
• запас под рост нагрузки и пики: минимум +30%

Итого: 4,2 ТБ x (1 + 0,30 + 0,15) = около 6,1 ТБ. С запасом +30% получаем примерно 8 ТБ полезной емкости. Дальше умножайте на коэффициент RAID (например, для RAID6 потребуется больше «сырой» емкости).

Где нужен SSD: база данных СЭД, журналы транзакций и индекс поиска обычно лучше держать на SSD. Так отклик стабильнее, и меньше «подвисаний» при массовых операциях. Архивы вложений чаще можно хранить на емких дисках, если доступ к старым документам редкий.

По памяти: если сейчас система уверенно работает на 64 ГБ, то под рост пользователей, кэш и индексацию разумно планировать 128 ГБ с запасом 20-30%. Это обычно дешевле, чем внеплановый апгрейд и простой.

Следующие шаги: как закрепить расчет и перейти к внедрению

Когда цифры по RAM и дискам посчитаны, их важно закрепить так, чтобы через полгода никто не спорил, откуда они взялись. Сведите входные данные в простой шаблон: сколько активных пользователей сейчас и будет через 12-24 месяца, сколько документов в день добавляется, какой средний размер вложения, сколько лет хранится архив, какие окна обслуживания допустимы. Отдельно зафиксируйте горизонт роста и согласуйте его с владельцем СЭД и ИБ.

Дальше проверьте требования к отказоустойчивости. Если простой недопустим, одной машины обычно мало. Заранее решите, будут ли отдельные роли (приложение, база, поиск) или кластер, и что вы делаете при сбое диска, узла или площадки.

План действий лучше держать коротким и проверяемым:

• утвердить шаблон входных данных и цель по росту
• определить архитектуру под отказоустойчивость и обслуживание
• запланировать нагрузочный тест и контрольную переиндексацию на копии данных
• составить план расширения: добавление дисков, увеличение RAM, перенос ролей на отдельный сервер
• зафиксировать, кто и как мониторит место, память, очередь индексации и время поиска

Нагрузочный тест полезнее всего делать на сценарии, близком к реальности: например, 200 одновременных пользователей, массовая загрузка сканов утром и переиндексация вечером. Так вы увидите узкое место (память, диски, поиск) еще до запуска.

Если нужен поставщик, который может не только продать «железо», но и собрать конфигурацию под реальные пики и рост СЭД, в Казахстане часто рассматривают GSE.kz (GSE) как локального производителя и системного интегратора, в том числе с линейкой серверов S200 Series и поддержкой 24/7.