Потребление памяти офисных пакетов: цифры и статистика тестов

Это фиксация трёх состояний на одной конфигурации.

Потребление памяти офисных пакетов статистика часто сводится к одной ошибке: системные требования принимают за фактический расход RAM. Отсюда появляются ложные сравнения. LibreOffice указывает минимум 256 МБ ОЗУ. Microsoft 365 требует 4 ГБ для Windows, либо 2 ГБ для 32-битной версии. ONLYOFFICE Desktop Editors и WPS Office ориентируются на 2 ГБ или больше. Эти цифры описывают среду запуска. Они не показывают, сколько памяти занял конкретный процесс после открытия конкретного файла.

Разница критична для старых ноутбуков, виртуальных рабочих столов, терминальных ферм и ПК с 4–8 ГБ ОЗУ. Там офисный пакет конкурирует за память не в вакууме. Параллельно работают браузер, агент защиты, клиент синхронизации, мессенджер, драйверы, индексатор и сама ОС. Небольшая аномалия в одном процессе превращается в активный swap, задержки интерфейса и рост времени сохранения.

Системные требования не являются бенчмарком

Минимум в спецификации производителя отвечает на другой вопрос: при какой конфигурации продукт в принципе может быть установлен и запущен. Иногда — с ограниченной функциональностью. Иногда — только на простом документе. Иногда — без учёта нагрузки от других процессов.

Для LibreOffice заявлены 256 МБ ОЗУ как минимум и 512 МБ как рекомендуемое значение на Windows и Linux. Для macOS указано 512 МБ. Это очень низкий порог, но из него нельзя вывести, что LibreOffice Writer потребляет 256 МБ или меньше в рабочем сценарии.

Microsoft для подписок Microsoft 365 Personal и Family указывает 4 ГБ оперативной памяти под Windows. Для 32-битной версии Windows обозначены 2 ГБ. Под macOS — 4 ГБ. Значение включает требования всего набора, платформы и поддерживаемой среды. Это не измерение Word, Excel или PowerPoint с открытым файлом.

ONLYOFFICE Desktop Editors указывает 2 ГБ ОЗУ или больше для Windows. При этом разработчик отдельно ограничивает применимость цифры: параметры рассчитаны на простейшие документы, а фактическая нагрузка зависит от сложности файла. WPS Office также рекомендует 2 ГБ или больше и связывает производительность с процессором, памятью и свободным местом на накопителе.

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

Требование к компьютеру — это граница совместимости. Потребление памяти процессом — наблюдаемая телеметрия. Подменять одно другим нельзя.

Для аудита инфраструктуры это означает простое правило: проектирование ёмкости по паспортным минимумам создаёт дефицит RAM ещё до запуска реальной нагрузки.

Что именно измеряет диспетчер задач

Фраза «программа съела 500 МБ» технически неполна. В Windows и других ОС память процесса отображается несколькими счётчиками. Они отвечают на разные вопросы.

• Рабочий набор процесса показывает страницы памяти, находящиеся в физической RAM в момент замера. Значение может снижаться, если ОС вытесняет редко используемые страницы.
• Private bytes отражает приватно выделенную память, которая не разделяется с другими процессами. Для анализа утечек этот параметр часто полезнее рабочего набора.
• Commit показывает объём закоммиченной виртуальной памяти. Он важен для оценки давления на общий лимит памяти системы.
• Пиковые значения фиксируют максимум за период работы процесса. Для документов с импортом изображений, пересчётом формул и экспортом PDF именно пик часто определяет, начнётся ли подкачка.
• Память дочерних процессов может не попадать в одну очевидную строку интерфейса. Это особенно актуально для приложений с отдельными компонентами обновления, рендеринга, проверки орфографии или интеграций.

Без указания метрики цифра не имеет достаточного веса. В независимом тесте с Apache OpenOffice и LibreOffice техническая метрика и инструмент замера не раскрыты. Поэтому значения 41,2, 95,0 и 195,1 МБ допустимо использовать только в исходном контексте: как показания потребления для пустого документа на указанном ПК. Нельзя объявлять их рабочим набором, private bytes или пиком нагрузки.

Неполная методика — не повод игнорировать тест. Это повод не расширять его выводы за пределы зафиксированного сценария.

Разрядность меняет профиль процесса

В тесте LibreOffice 7.3.4 32-битная версия показала около 95,0 МБ, а 64-битная — около 195,1 МБ при открытом пустом Writer. Разрыв заметный. Причина не сводится к тезису «64-bit всегда потребляет вдвое больше». Такой вывод не подтверждён.

64-битная сборка использует более широкие указатели и может иначе размещать структуры данных, библиотеки и кэш. На результат влияют архитектура ОС, набор подключённых библиотек, механизмы защиты памяти, шрифты, локали, плагины и состояние кэша после старта. Даже при одинаковой версии приложения два запуска могут показать отличающиеся значения.

В рамках конкретного измерения наблюдалась следующая картина:

Эта таблица не позволяет ранжировать современные LibreOffice, Microsoft 365, WPS Office и ONLYOFFICE. Версии различаются. Набор приложений различается. Отсутствует единый файл. Неизвестна метрика. Нет данных об актуальных сборках в одной лабораторной среде.

Но один практический вывод всё же есть. При миграции с 32-битного офисного пакета на 64-битный нельзя считать объём памяти неизменной величиной. Это отдельная переменная в расчёте ёмкости.

Пустой документ — почти нулевая нагрузка

Нагрузка Office на систему в цифрах начинает расти не в момент запуска редактора, а после появления данных. Пустой DOCX — это инициализация интерфейса, библиотек, шрифтов и базовых компонентов. Рабочий файл добавляет новый слой потребления.

Наиболее частые источники роста RAM:

1. Изображения и сканы. В документе может находиться сжатый JPEG, но для отображения и обработки редактору требуется развернуть изображение в памяти. Несколько страниц сканов высокого разрешения дают иной профиль, чем текстовый договор на 20 страниц.

2. Таблицы и формулы. В табличных редакторах память занимает не только видимый диапазон. Используются структуры ячеек, формулы, кэш вычислений, стили, сводные таблицы, ссылки на внешние данные и история действий. XLSX с тысячами формул нельзя оценивать по размеру файла на диске.

3. Режим совместимости. Импорт DOCX, XLSX и PPTX в альтернативный пакет требует разбора формата и преобразования внутренних объектов. Сложная вёрстка, встроенные шрифты, диаграммы и нестандартные стили увеличивают поверхность ошибок и нагрузку на процесс.

4. Макросы и надстройки. VBA-проекты, COM-надстройки, плагины проверки правописания, корпоративные шаблоны и интеграции с СЭД запускают дополнительный код. Это уже не только вопрос производительности. Это новый вектор атаки и источник нестабильности.

5. Совместное редактирование и облачная синхронизация. Локальный документ может сопровождаться кэшем изменений, фоновым обменом и конфликтами версий. При анализе надо смотреть не только на основной процесс редактора.

6. История и отмена операций. Вставка больших фрагментов, массовое форматирование или пересчёт книги создают временные пики. Среднее значение памяти за спокойный период скрывает проблему.

Для планирования достаточно не среднего расхода. Нужен пик на реальном файле и в реальном наборе фоновых процессов.

Потребление оперативной памяти текстовыми редакторами особенно часто недооценивают в средах с большими PDF-сканами и шаблонами с графикой. Формально это текстовый документ. Фактически — контейнер из десятков изображений, шрифтов и объектов вёрстки.

Почему «лёгкий пакет» может стать тяжёлым

Сравнение тяжести офисных пакетов обычно строят по запуску Writer, Word или WPS Writer с пустой страницей. Такой тест годится для оценки стартового следа. Для работы отдела он почти бесполезен.

В корпоративной инфраструктуре пакет работает с типовыми артефактами: договорами, выгрузками ERP, финансовыми моделями, презентациями, сканами, отчётами с диаграммами. Нагрузка формируется связкой «приложение + файл + расширения + ОС + фоновые агенты».

Типовая последовательность инцидента выглядит предсказуемо:

• пользователь открывает большую книгу с внешними ссылками;
• редактор начинает импорт и пересчёт;
• рабочий набор процесса растёт;
• свободная RAM сокращается;
• ОС активирует сжатие памяти или файл подкачки;
• интерфейс зависает на операциях сохранения;
• пользователь запускает вторую копию файла или завершает процесс принудительно;
• появляется риск повреждения локальной версии и конфликта синхронизации.

В журналах такая ситуация не всегда выглядит как авария приложения. Часто нет явного crash-события. Есть косвенные признаки: увеличение commit charge, всплеск hard faults, задержка операций ввода-вывода, повторный запуск процесса, создание временных файлов, несинхронизированные копии в облачном каталоге.

Отдельная проблема — устройства с 4 ГБ RAM. Microsoft 365 формально поддерживается на такой конфигурации Windows. Это не означает комфортной работы Word, Excel, браузера с несколькими вкладками, Teams и защитного агента одновременно. Формальное соответствие требованиям не отменяет конкуренцию за память.

На ПК с 8 ГБ ситуация лучше, но не гарантирована. В упомянутом тесте сама тестовая система имела 8 ГБ. Из этого не следует, что 8 ГБ достаточно для любого документа. Это лишь подтверждает, что измерения пустых Writer выполнялись в такой среде.

Как строить собственный замер без ложной точности

Единого свежего независимого бенчмарка, где актуальные Microsoft 365, LibreOffice, ONLYOFFICE и WPS Office протестированы на одной машине, с одинаковыми файлами и одинаковой метрикой памяти, нет. Значит, универсальной таблицы «этот пакет потребляет X МБ» нет тоже.

Корректный путь — измерять свой рабочий профиль. Не усреднённый офис из обзора. Свой.

Минимальная методика состоит из пяти этапов.

1. Зафиксировать конфигурацию. Версия ОС, разрядность, объём RAM, файл подкачки, версия офисного пакета, обновления, антивирус, список активных расширений. Без этого результаты нельзя сравнивать даже внутри одной организации.

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

3. Выбрать счётчики до начала теста. Для Windows это как минимум рабочий набор, private bytes, commit и пиковые значения процесса. Дополнительно фиксируются общая доступная память, активность файла подкачки и загрузка диска.

4. Повторить сценарий. Холодный запуск после перезагрузки и повторный запуск после прогрева кэшей — разные состояния. Открытие файла, прокрутка, поиск, пересчёт, вставка изображения, сохранение и экспорт PDF должны фиксироваться отдельно.

5. Сопоставить результат с пользовательским действием. Рост памяти сам по себе не является дефектом. Проблема начинается там, где пик приводит к подкачке, зависанию интерфейса, отказу сохранения или аварийному завершению.

В отчёте не стоит писать «LibreOffice потребляет 300 МБ». Корректная запись выглядит иначе: «LibreOffice версии N на Windows версии N при открытии файла класса N достиг пикового значения N по метрике N; в системе с N ГБ RAM наблюдалась или не наблюдалась подкачка». Это длиннее. Зато вывод проверяем.

Риск находится не только в RAM

Рост потребления памяти иногда принимают за чисто эксплуатационную проблему. Для аудитора это также индикатор поверхности риска.

Необъяснимое увеличение памяти после открытия стандартного файла может быть следствием сложного документа, повреждённого объекта, нестабильного расширения или аномального содержимого. Сам факт роста не подтверждает компрометацию. Но его нельзя списывать без проверки, если одновременно наблюдаются сетевые обращения, запуск дочерних процессов, создание исполняемых файлов во временных каталогах или отключение защитных компонентов.

Особое внимание требуется к документам с макросами, внешними ссылками, OLE-объектами и архивными форматами с необычной структурой. Офисный файл остаётся одним из самых удобных носителей для начального доступа. Нагрузка на память в таком случае — побочный симптом. Основной объект анализа — цепочка выполнения.

Для рабочего места полезно разделить два контура:

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

Смешивать эти контуры не следует. Дефицит RAM не создаёт уязвимость. Но он маскирует аномалии и ухудшает реакцию пользователя: зависшее приложение чаще закрывают принудительно, предупреждения игнорируют, несохранённые версии теряют.

Митигация: строгий минимум действий

Оценка потребления памяти офисных пакетов должна завершаться не спором о «лёгком» редакторе, а измеримым планом.

• Зафиксировать версии офисных пакетов и их разрядность на управляемых устройствах.
• Отделить системные требования производителя от фактических замеров процессов.
• Собрать тестовый набор из реальных DOCX, XLSX, PPTX, ODT и ODS без чувствительных данных.
• Измерять рабочий набор, private bytes, commit и пиковые значения в одной методике.
• Проводить тесты после холодного запуска и после повторного открытия документов.
• Отдельно проверять документы со сканами, формулами, внешними ссылками, макросами и встроенными объектами.
• Контролировать подкачку, задержки диска и свободную память всей системы, а не только один процесс.
• Удалять неподдерживаемые надстройки и расследовать необъяснимые дочерние процессы.
• Не переносить результаты старых версий LibreOffice и OpenOffice на актуальные сборки без повторного замера.
• Планировать запас RAM по пиковому рабочему сценарию, а не по пустому документу и не по строке «минимум» в спецификации.

Статистика по памяти офисных пакетов полезна только при сохранении контекста. На сегодня доступны отдельные точки измерения и требования производителей. Единого сравнения для современных версий нет. Следовательно, утверждение, что конкретный пакет всегда легче другого, не проходит аудит. Реальный ответ формируется на конкретном ПК, конкретном файле и конкретной метрике памяти.