Ubuntu Server 24.04: минимальная и стандартная версии — сравнение показателей производительности.

Виртуальный частный сервер испытывает нехватку памяти, поэтому вы переустанавливаете Ubuntu Server 24.04 LTS и сталкиваетесь с выбором: стандартная установка Ubuntu Server или Ubuntu Server (в свернутом виде). ​​Заманчиво предположить, что меньшее количество пакетов автоматически означает более быстрые веб-запросы, более короткие запросы к базе данных и более высокую пропускную способность процессора. Разница более тонкая. Меньший начальный набор пакетов может уменьшить использование диска и фоновую активность, но сам по себе он не делает процессор или устройство хранения данных быстрее.

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

Примечание (9 октября 2026 г.): В этой статье описывается воспроизводимый метод бенчмаркинга и результаты, которые может показать каждый показатель. В ней не приводятся исходные измеренные значения двух одинаковых установок Ubuntu 24.04. В качестве результатов тестирования не представлены непроверенные данные по оперативной памяти, дисковому пространству, времени загрузки или пропускной способности.

В чём разница между стандартной и минимизированной версией Ubuntu Server?

Установщик Subiquity в Ubuntu Server предлагает два варианта установки: ubuntu-serverстандартный (по умолчанию) и ubuntu-server-minimalминимизированный. Компания Canonical документирует эти идентификаторы источников и рекомендует проверять casper/install-sources.yamlвыбранный ISO-образ, поскольку идентификаторы установщика могут меняться. См. документацию Canonical по автоматической установке Subiquity .

Обе системы — Ubuntu Server 24.04 LTS, а не две разные оптимизированные архитектуры процессоров или отдельные дистрибутивы Linux. Главное отличие заключается в программном обеспечении, поставляемом во время установки. Точный список пакетов зависит от версии установочного носителя, дополнительных опций, обновлений, драйверов и впоследствии установленных приложений. Не следует предполагать, что список, опубликованный для одной сборки образа, будет неизменным для всех установщиков 24.04.

Не следует путать вариант с минимизированным сервером с минимальными облачными образами Ubuntu , отдельным семейством образов, или с вариантом минимальной установки Ubuntu Desktop. В примечаниях к выпуску Ubuntu 24.04 LTS обсуждается существенное сокращение количества пакетов и размера загружаемых минимальных облачных образов по сравнению с более ранними версиями. Опубликованные примеры облачных образов не являются контролируемым сравнением стандартных и минимизированных ISO-образов для работающих серверов, и их значения не следует использовать повторно, как если бы они таковыми были.

Какие показатели производительности имеют значение?

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

Начните с создания адекватной тестовой установки, а не с секундомера.

Создайте две виртуальные машины на основе одного и того же ISO-образа Ubuntu Server 24.04 LTS: одну стандартную и одну минимизированную. Назначьте им одинаковое количество виртуальных процессоров, объем оперативной памяти, виртуальные диски, файловые системы, режим загрузки, настройки гипервизора, сетевое подключение и класс хранилища. Для физических машин используйте эквивалентное оборудование и проведите тестирование в аналогичных температурных и энергетических условиях. Не используйте эти машины в производственной среде.

На обеих системах примените одинаковые обновления безопасности и перезагрузите систему. Запишите значения cat /etc/os-release, uname -r, и lscpu, а также версию образа установщика и дату тестирования. Ubuntu Server 24.04 обычно использует ядро ​​общего назначения (GA), но может опционально использовать ядра с аппаратной поддержкой (HWE); использование разных ядер помешало бы сравнению только по типу установки. В документации ядра Ubuntu по ядрам GA и HWE объясняется это различие.

Соберите два набора измерений:

1. Базовый вариант чистой установки: сразу после идентичных обновлений, перед установкой рабочей нагрузки. Это позволяет выявить практические различия в настройках установки по умолчанию.
2. Базовый уровень, приближенный к производственному: после установки одних и тех же пакетов приложений, включения одних и тех же служб и применения идентичных конфигураций. Это показывает, имеет ли значение разница в первоначальном объеме занимаемой памяти.

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

Сначала измерьте простые различия.

1. Подсчитайте количество установленных пакетов и проверьте наличие свободного места на диске.

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

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

Запишите количество файлов, используемое пространство в корневой файловой системе и структуру файловой системы. Убедитесь, что размеры корневых разделов сопоставимы; в противном случае, видимая разница может возникнуть из-за разметки диска. Использование диска также включает журналы, кэш пакетов и метаданные файловой системы, поэтому одинаковое время установки и сопоставимая история обновлений имеют значение.

2. Сравнивайте доступный объем оперативной памяти, а не только "свободную" память.

После того, как обе системы проведут в режиме ожидания в течение определенного периода времени, выполните следующие действия:

free -h
systemctl --type=service --state=running --no-pager

Обратите внимание на availableстолбец в файле, freeа также на другие столбцы used. Linux использует обычно неиспользуемую память для кэширования, которую можно освободить, когда она понадобится приложениям. Меньшее значение в freeстолбце не обязательно указывает на проблему. Проверьте, относится ли дополнительное использование памяти к службам, которые вы действительно планируете сохранить.

3. Сравните время загрузки и выявите медленно работающие службы.

При каждой загрузке используйте инструменты systemd, входящие в состав дистрибутива:

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze timeСообщается о времени загрузки, но это не обязательно означает, что приложение готово принимать запросы. Список blameтакже может ввести в заблуждение, поскольку инициализация модулей может происходить параллельно, а некоторые типы служб измеряются по-разному. Изучите критическую цепочку, а затем отдельно проверьте именно ту конечную точку службы, которая вас интересует. Эти ограничения описаны в руководстве по systemd-analyze для Ubuntu 24.04 .

Например, если сервер использует HTTP API, измерьте время от перезагрузки до момента успешного выполнения запроса к API. Если на хосте работает база данных, проверьте, успешно ли выполняется запрос. Это измерение готовности более информативно, чем измерение достижения операционной системой целевого состояния загрузки.

Затем протестируйте процессор и хранилище данных под контролируемой нагрузкой.

4. Запустите одинаковую нагрузку на ЦП на обеих машинах.

Для простого сравнения производительности процессора установите идентичную версию sysbench на каждую из виртуальных машин после записи данных о производительности после чистой установки. Затем выполните ту же команду:

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

Сравните количество событий в секунду и задержку при повторных запусках. В документации проекта sysbench приведен синтаксис команд и встроенный тест ЦП. Используйте второй запуск с тем же увеличенным количеством потоков только в том случае, если он соответствует назначенному количеству ЦП. Уменьшение набора пакетов само по себе не оправдывает утверждение об ускорении ЦП; неожиданные различия должны побудить к проверке конкуренции за ЦП хоста, поведения тактовой частоты, версии ядра и фоновых процессов.

5. Тестирование дискового ввода-вывода без использования бенчмарка на рабочем диске.

Для дополнительного эксперимента по хранению данных установите fio на обе тестовые машины и создайте идентичные тестовые файлы на временной файловой системе с достаточным свободным местом. Следующие команды создадут файл размером 256 МиБ в домашнем каталоге текущего пользователя, а затем запустят для этого файла задачу чтения с ограничением по времени:

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

Запустите обе машины с идентичными дисками и параметрами ввода-вывода. Файл размером 256 МиБ может быть слишком мал для точного моделирования вашей базы данных или устройства хранения; увеличивайте размер файла и изменяйте рабочую нагрузку только при наличии достаточного временного пространства и безопасной тестовой среды. Записывайте распределение IOPS, пропускной способности и задержки, а не только наибольшее значение пропускной способности. В руководстве по fio в Ubuntu 24.04 описаны параметры рабочей нагрузки. Никогда не направляйте тесты записи на необработанное блочное устройство, содержащее полезные данные.

6. В последнюю очередь протестируйте реальное приложение.

Установите на обе машины абсолютно одинаковый стек приложений, включая версии веб-приложений или баз данных, ограничения на количество подключений, логирование, TLS, кэширование и мониторинг. Отправьте эквивалентный набор запросов с отдельного генератора нагрузки с той же степенью параллелизма и продолжительностью теста. Измерьте пропускную способность, медианную и 95-процентную задержку ответа, частоту ошибок, загрузку ЦП, нагрузку на память и подкачку. Используйте один и тот же набор данных и убедитесь, что ни одна из машин не использует общую ресурсоемкую систему хранения данных, не учитывая при этом конкуренцию за ресурсы.

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

Как интерпретировать противоречивые результаты сравнительных тестов?

• Меньшее количество пакетов, но одинаковые показатели производительности ЦП: это полностью соответствует действительности. Меньшее количество установленных инструментов не обязательно влияет на вычислительную производительность.
• Меньшее использование дискового пространства, но одинаковый показатель IOPS: свободное пространство и скорость устройства — это разные свойства. Обратите внимание на аппаратное обеспечение хранилища, схему ввода-вывода, файловую систему и кэширование.
• Более быстрая загрузка systemd, но столь же медленная готовность приложений: узким местом может быть запуск приложения, сетевые зависимости или восстановление базы данных.
• Меньше неиспользуемой оперативной памяти, но та же задержка запроса: минимизация может обеспечить полезный запас емкости, при этом текущая рабочая нагрузка не ограничена объемом памяти.
• Резкие колебания результатов между запусками: перед объявлением победителя изучите влияние «шумных соседей», масштабирование частоты процессора, обновления, запланированные задачи, температурное дросселирование и прогрев кэша.

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

Стоит ли переводить существующий сервер в свернутый режим?

Обычно это делается не только ради бенчмарков. Для рабочей стандартной установки сначала проверьте фактически активные службы и измерьте производительность приложения. Удаление ненужных пакетов может не улучшить и без того стабильную работу системы, а неосторожное удаление пакетов может нарушить работу сети, восстановления, логирования или удаленного управления. В рекомендациях Canonical по безопасности Ubuntu относительно ненужных пакетов рекомендуется выбирать подходящую минимальную начальную установку вместо того, чтобы без разбора удалять пакеты по умолчанию.

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

Безопасность — это взаимосвязанные, но отдельные понятия: меньшее количество пакетов может уменьшить объем программного обеспечения, которое необходимо поддерживать, но это не является доказательством снижения количества уязвимостей CVE. Оба типа установки по-прежнему требуют обновлений безопасности и усиления защиты сервисов.

Контрольный список окончательной проверки

• Убедитесь, что на обеих машинах установлена ​​Ubuntu Server 24.04 LTS с одинаковой архитектурой, уровнем исправлений, версией ядра и поколением установщика.
• Задокументируйте выбор стандартного или минимизированного варианта, дополнительные параметры установщика и услуги, добавленные впоследствии.
• Сравните количество пакетов, использование корневой файловой системы и доступную память после идентичных обновлений и периода простоя для стабилизации.
• Повторите измерения готовности к загрузке и работе приложений после нескольких перезагрузок, сообщая медианные значения, а не один лучший результат.
• Используйте соответствующие параметры для загрузки ЦП, хранилища и приложений, а также регистрируйте распределение ошибок и задержек.
• Запустите приложение с идентичными зависимостями, конфигурацией и данными, а затем определите, влияют ли какие-либо различия на производительность, надежность или время развертывания.

Практический вывод: минимизированная версия обычно является лучшим вариантом для серверов с узкой областью применения и автоматизированным управлением; стандартная версия предлагает более полный набор инструментов по умолчанию. Ни один из вариантов не является универсально более быстрым. На Ubuntu Server 24.04 LTS наиболее полезным бенчмарком является тот, который измеряет производительность вашей службы при фактической нагрузке, которую она должна обрабатывать.