SLES 15 против RHEL 9: сравнение производительности корпоративных серверов

Не существует универсального лидера по производительности между SUSE Linux Enterprise Server 15 и Red Hat Enterprise Linux 9. Обоснованный ответ зависит от конкретного пакета обновлений или минорного релиза, оборудования, обновлений ядра, профиля настройки, стека приложений и рабочей нагрузки. Текущее руководство по настройке SUSE SLES 15 SP7 и документация Red Hat по RHEL 9 описывают возможности настройки; они не устанавливают контролируемый, универсальный результат прямого сравнения скорости.

Это различие важно, потому что в документации SLES 15 SP7 указано ядро ​​Linux 6.4, в то время как Red Hat указывает, что RHEL 9 основан на ядре 5.14, и отмечает, что в его ядро ​​интегрированы более новые изменения. Одних только этих обозначений версий недостаточно, чтобы предсказать, какой дистрибутив быстрее запустит базу данных, веб-сервис или виртуальную машину. Воспринимайте их как характеристики продукта, а затем проведите сравнительный анализ производительности рабочей нагрузки, которую вы действительно планируете использовать.

Что можно проверить относительно SLES 15 и RHEL 9?

Перед сравнением машин запишите точные установленные версии и активный профиль на каждой из них. Например, соберите данные о версиях cat /etc/os-release, uname -r, и sudo tuned-adm active. Используйте вывод версий, а не маркетинговое название «SLES 15» или «RHEL 9», в качестве метки для теста.

Действительно ли более новая базовая архитектура ядра SLES 15 SP7 делает его быстрее, чем RHEL 9?

Само по себе это не так. Базовые версии ядра не являются показателем производительности. Red Hat поддерживает стабильную основную версию ядра и переносит отдельные исправления и функции; поэтому ядро ​​RHEL 9, сообщающее о версии 5.14, может содержать функциональность из более новых версий от разработчиков. SUSE также поддерживает и обновляет свою собственную поддерживаемую версию ядра. Поведение приложения зависит от конкретных исправлений, драйверов, поддержки оборудования, конфигурации и пути выполнения кода рабочей нагрузкой.

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

Эквивалентны ли стандартные профили TuneD?

Не следует предполагать полную эквивалентность. TuneD существует в обеих экосистемах, но установленный набор профилей, автоматические рекомендации, содержимое профилей и локальные переопределения могут отличаться. В руководстве SUSE SLES 15 SP7 описаны рекомендации по профилям на основе конфигурации системы. В документации Red Hat для RHEL 9 также говорится, что автоматический выбор профиля зависит от типа машины и настроек системы. Даже если оба хоста сообщают о профиле с одинаковым именем, проверьте, какие изменения он вносит, прежде чем считать конфигурации идентичными.

Действие: запустите sudo tuned-adm activeкоманды sudo tuned-adm listна каждом хосте. Сохраните выходные данные и любые файлы пользовательских профилей. Для сравнения «установки по умолчанию» сохраните поддерживаемые поставщиком настройки по умолчанию и задокументируйте их. Для сравнения «максимально достижимой производительности» настройте каждую операционную систему отдельно, используя рекомендации поставщика, а затем сообщите об использованных профилях и настройках.

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

Какая система, скорее всего, лучше справится с вашей рабочей нагрузкой?

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

• Приложения, ресурсоемкие для ЦП: используйте стандартный компилятор, среду выполнения, библиотеки и настройки безопасности. Измеряйте количество выполненной работы в секунду и время работы ЦП. Микротест может помочь объяснить разницу, но он не может заменить тестирование приложения.
• Для баз данных и ресурсоемких сервисов: используйте репрезентативную версию базы данных, схему, размер рабочего набора, параллелизм и политику сохранения данных. Отслеживайте количество транзакций в секунду наряду со средней и экстремальной задержкой; более высокая средняя скорость может скрывать более медленные запросы.
• Для ресурсоемких сервисов: сохраняйте ту же модель диска, прошивку контроллера, файловую систему, параметры монтирования, набор данных и глубину очереди. Измеряйте фактическое соотношение операций чтения/записи и распределение задержек, а не только пиковую последовательную пропускную способность.
• Сетевые службы: поддерживайте согласованность параметров сетевой карты, микропрограммы, пути коммутатора, MTU, настроек разгрузки и нагрузки на клиентов. Измеряйте пропускную способность и задержку приложений при ожидаемом количестве подключений.
• Виртуальные машины или контейнеры: сравнение на одном и том же гипервизоре или стеке контейнеров, с одинаковым распределением ЦП и памяти, политиками хоста, профилем гостевой системы и образом. Учитывайте плотность и конкуренцию за ресурсы, если это отражает производственную среду.
• Системы, чувствительные к энергопотреблению: сообщают об энергии на единицу выполненной работы, а не только о пиковой скорости. Система, потребляющая меньше энергии, но работающая дольше, не обязательно будет использовать меньше энергии в целом для пакетной обработки задания.

Если вы не знаете, куда уходит время, проведите профилирование приложения или отслеживайте загрузку ЦП, давление памяти, время ожидания ввода-вывода, загрузку сети и очереди выполнения перед настройкой. В противном случае, более быстрый профиль ЦП не устранит узкое место в хранилище.

Как провести объективное сравнение?

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

1. Подберите платформу в соответствии с вашими потребностями: по возможности используйте идентичные модели серверов с одинаковой ступенчаткой процессора, объемом памяти, BIOS/прошивкой, хранилищем данных, сетевой картой и ограничениями по энергопотреблению.
2. Зафиксируйте подробные сведения о программном обеспечении: запишите пакет обновлений и уровень обновления SLES, минорный релиз и уровень обновления RHEL, пакет ядра, версию приложения, среду выполнения/компилятор, микропрограмму и соответствующие меры безопасности.
3. Настройка параметров: запись профилей TuneD, режима работы ЦП или энергосбережения, настроек NUMA и больших страниц памяти, параметров файловой системы и монтирования, а также параметров приложения. Оставьте значения по умолчанию для проверки "из коробки" или целенаправленно настройте обе системы для оптимизированного тестирования.
4. Используйте данные и нагрузку, максимально приближенные к производственным: сделайте тест достаточно продолжительным, чтобы достичь стабильного поведения, и включите в него необходимую параллельность и размер данных. Определите состояние кэша и процедуру прогрева, чтобы каждый запуск начинался сопоставимо.
5. Повторите и сообщите о вариациях: по возможности меняйте порядок тестирования, повторяйте запуски и указывайте медианное значение плюс разброс между запусками. Сообщите о пропускной способности вместе с задержкой p95/p99, потреблением ресурсов и ошибками, где это уместно.
6. Ведите воспроизводимый учет: публикуйте конфигурацию системы, версию бенчмарка, команды или скрипты, различия в настройках и исходные результаты. Если результат получен для общедоступного стандартизированного бенчмарка, следуйте действующим правилам отчетности этого бенчмарка.

Правила SPEC для процессоров 2017 года требуют полного раскрытия условий, влияющих на производительность, и достаточной детализации конфигурации для воспроизведения общедоступного результата. Это полезный стандарт даже при тестировании внутренней нагрузки. Бенчмарка с одним необъяснимым результатом недостаточно, чтобы определить, был ли результат получен из-за операционной системы, флагов компилятора, настроек BIOS или другого оборудования.

Что известно, что зависит от вашей конфигурации, а что еще не доказано?

• Известно: в текущей документации SLES 15 SP7 и RHEL 9 описаны различные потоки ядра и конфигурация производительности на основе TuneD. Оба производителя предоставляют инструменты для настройки под конкретные рабочие нагрузки.
• Зависит от среды: пропускная способность, задержка, энергопотребление, время загрузки, плотность виртуальных машин, поведение драйверов и усилия, необходимые для поддержания согласованности настроек. Эти параметры различаются в зависимости от оборудования, приложения, версии и операционной политики.
• Из изученной документации не установлено: что SLES 15 однозначно быстрее, чем RHEL 9, что RHEL 9 однозначно быстрее, чем SLES 15, или что одна базовая версия ядра гарантирует преимущество в производительности для любой рабочей нагрузки.

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

Официальные ссылки

• SUSE: Руководство по анализу и настройке системы SLES 15 SP7
• SUSE: Примечания к выпуску SLES 15 SP7
• Red Hat: управление, мониторинг и обновление ядра RHEL 9
• Red Hat: Начало работы с TuneD в RHEL 9
• Red Hat: Настройка профилей TuneD
• СПЕЦИФИКАЦИЯ: Правила запуска и формирования отчетов CPU 2017
• SPEC: Обзор CPU 2017 и принципы добросовестного использования