SLES 15 kontra RHEL 9: Porównanie wydajności serwerów korporacyjnych

Nie ma uniwersalnego zwycięzcy pod względem wydajności pomiędzy SUSE Linux Enterprise Server 15 a Red Hat Enterprise Linux 9. Prawdopodobna odpowiedź zależy od konkretnego dodatku Service Pack lub wersji pomocniczej, sprzętu, aktualizacji jądra, profilu dostrajania, stosu aplikacji i obciążenia. Aktualny przewodnik dostrajania SUSE SLES 15 SP7 oraz dokumentacja Red Hat RHEL 9 opisują możliwości dostrajania; nie przedstawiają one kontrolowanego, uniwersalnego wyniku porównawczego w zakresie szybkości.

To rozróżnienie ma znaczenie, ponieważ dokumentacja SLES 15 SP7 wskazuje na jądro Linuksa 6.4, podczas gdy Red Hat dokumentuje RHEL 9 jako oparte na jądrze 5.14 i zaznacza, że ​​wnosi do niego nowsze zmiany. Same etykiety wersji nie pozwalają przewidzieć, która dystrybucja będzie szybciej obsługiwać bazę danych, usługę sieciową lub maszynę wirtualną. Potraktuj je jako fakty dotyczące produktu, a następnie przeprowadź testy porównawcze obciążenia, które faktycznie planujesz obsługiwać.

Co można zweryfikować na temat SLES 15 i RHEL 9?

Przed porównaniem maszyn zanotuj dokładne zainstalowane wersje i aktywny profil na każdej z nich. Na przykład zbierz cat /etc/os-release, uname -ri sudo tuned-adm active. Jako etykiety testowej użyj danych wyjściowych wersji, a nie nazwy marketingowej „SLES 15” lub „RHEL 9”.

Czy nowsza wersja jądra SLES 15 SP7 sprawia, że ​​jest on szybszy niż RHEL 9?

Samo w sobie nie. Podstawowe wersje jądra nie stanowią wyniku benchmarku. Red Hat utrzymuje stabilny strumień jądra w głównych wydaniach i przenosi wybrane poprawki i funkcje; dlatego jądro RHEL 9 zgłaszające wersję 5.14 może zawierać funkcjonalność z nowszych wydań. SUSE również utrzymuje i aktualizuje własny strumień obsługiwanych jąder. Działanie aplikacji zależy od konkretnych poprawek, sterowników, obsługi sprzętu, konfiguracji i ścieżki kodu, z którą pracuje obciążenie.

Działanie: zapisz pełną wersję pakietu jądra i poziom wydania dla obu systemów testowych. Podczas badania funkcji lub sterownika, sprawdź informacje o wydaniu i macierz wsparcia dla każdego dostawcy dla konkretnego wydania, zamiast porównywać tylko dwie pierwsze liczby z listy uname -r.

Czy domyślne profile TuneD są równoważne?

Nie należy zakładać równoważności. TuneD istnieje w obu ekosystemach, ale zainstalowany zestaw profili, automatyczne rekomendacje, zawartość profilu i lokalne nadpisania mogą się różnić. Podręcznik SUSE SLES 15 SP7 opisuje rekomendacje dotyczące profili w oparciu o konfigurację systemu. Dokumentacja Red Hat RHEL 9 również podaje, że automatyczny wybór profilu zależy od typu maszyny i ustawień systemowych. Nawet jeśli oba hosty zgłaszają profil o tej samej nazwie, należy sprawdzić, co zmienia, zanim potraktuje się konfiguracje jako identyczne.

Działanie: uruchom sudo tuned-adm activei sudo tuned-adm listna każdym hoście. Zapisz dane wyjściowe i wszelkie pliki profili niestandardowych. Aby porównać „domyślną instalację”, zachowaj ustawienia domyślne obsługiwane przez każdego dostawcę i udokumentuj je. Aby porównać „najlepszą możliwą wydajność”, dostrój każdy system operacyjny osobno, korzystając ze wskazówek dostawcy, a następnie zgłoś używane profile i ustawienia.

Nie stosuj wszystkich profili wydajnościowych jednocześnie. Profile mogą kolidować – na przykład ustawienie pamięci masowej zorientowane na przepustowość może zostać osłabione przez inne ustawienie, które zwiększa prędkość obrotową dysku. Zmieniaj jedną istotną zmienną na raz, upewnij się, że usługa pozostaje stabilna i przechowuj rejestr wycofań.

Który system prawdopodobnie lepiej sprawdzi się w Twoim przypadku?

Obciążenie pracą zazwyczaj ma większe znaczenie niż szeroka dystrybucja. To priorytety testów, a nie obietnice dotyczące tego, który dostawca wygra:

• Aplikacje obciążające procesor: użyj kompilatora produkcyjnego, środowiska uruchomieniowego, bibliotek i ustawień zabezpieczeń. Zmierz wykonaną pracę na sekundę i czas procesora. Mikrobenchmark może pomóc wyjaśnić różnicę, ale nie zastąpi testu aplikacji.
• Bazy danych i usługi wymagające dużej ilości pamięci: użyj reprezentatywnej wersji bazy danych, schematu, rozmiaru zestawu roboczego, współbieżności i polityki trwałości. Śledź liczbę transakcji na sekundę, uwzględniając medianę i opóźnienie końcowe; wyższa średnia prędkość może ukryć wolniejsze żądania.
• Usługi intensywnie wykorzystujące pamięć masową: zachowaj ten sam model dysku, oprogramowanie układowe kontrolera, system plików, opcje montowania, zestaw danych i głębokość kolejki. Zmierz rzeczywistą proporcję odczytu/zapisu i rozkład opóźnień, a nie tylko szczytową przepustowość sekwencyjną.
• Usługi sieciowe: utrzymuj spójność karty sieciowej, oprogramowania sprzętowego, ścieżki przełącznika, MTU, ustawień odciążania i obciążenia klienta. Zmierz przepustowość i opóźnienie aplikacji przy oczekiwanej liczbie połączeń.
• Maszyny wirtualne lub kontenery: porównaj na tym samym hiperwizorze lub stosie kontenerów, z tym samym przydziałem procesora i pamięci, zasadami hosta, profilem gościa i obrazem. Uwzględnij gęstość i rywalizację o zasoby, jeśli odzwierciedlają one środowisko produkcyjne.
• Systemy wrażliwe na zużycie energii: raportuj zużycie energii na jednostkę pracy, a nie tylko na prędkość szczytową. System, który zużywa mniej energii, ale zajmuje więcej czasu, może nie zużywać mniej energii całkowitej na zadanie wsadowe.

Jeśli nie wiesz, gdzie ucieka czas, sprofiluj aplikację lub monitoruj obciążenie procesora, obciążenie pamięci, oczekiwanie na wejście/wyjście, nasycenie sieci i kolejki uruchomieniowe przed dostrojeniem. W przeciwnym razie szybszy profil procesora nie rozwiąże problemu wąskiego gardła w pamięci masowej.

Jak przeprowadzić uczciwe porównanie?

Najpierw zdecyduj, na które pytanie odpowiadasz. Pytanie „Który system jest szybszy bezpośrednio po instalacji?” różni się od pytania „Który system jest szybszy po dostrojeniu środowiska produkcyjnego?”. Nie porównuj dostrojonej konfiguracji jednej dystrybucji z domyślnymi ustawieniami innej, nazywając wynik porównaniem systemu operacyjnego.

1. Dopasuj platformę: w miarę możliwości używaj identycznych modeli serwerów, z taką samą częstotliwością taktowania procesora, liczbą pamięci, systemem BIOS/oprogramowaniem sprzętowym, pamięcią masową, kartą sieciową i limitami zasilania.
2. Zamroź szczegóły oprogramowania: zanotuj pakiet serwisowy SLES i poziom aktualizacji, wersję pomocniczą RHEL i poziom aktualizacji, pakiet jądra, wersję aplikacji, środowisko uruchomieniowe/kompilator, oprogramowanie sprzętowe i stosowne zabezpieczenia.
3. Konfiguracja sterowania: rejestruj profile TuneD, regulator procesora lub tryb zasilania, ustawienia NUMA i HBP, opcje systemu plików i montowania oraz parametry aplikacji. Zachowaj ustawienia domyślne na potrzeby testu gotowego do użycia lub celowo dostosuj oba systemy, aby zoptymalizować test.
4. Użyj danych i obciążenia zbliżonych do produkcyjnych: spraw, aby test był wystarczająco długi, aby osiągnąć stabilne zachowanie i uwzględnić współbieżność oraz rozmiar danych, które mają znaczenie. Zdefiniuj stan pamięci podręcznej i procedurę rozgrzewania, aby każdy przebieg rozpoczynał się w porównywalny sposób.
5. Powtórz i zgłoś zmienność: zmień kolejność testów, jeśli to możliwe, powtórz przebiegi i pokaż medianę plus różnicę między przebiegami. Zgłoś przepustowość wraz z opóźnieniem p95/p99, zużyciem zasobów i błędami, jeśli to istotne.
6. Prowadź powtarzalny zapis: publikuj konfigurację systemu, wersję testu porównawczego, polecenia lub skrypty, różnice w dostrajaniu oraz surowe wyniki. Jeśli wynik dotyczy publicznego, ujednoliconego testu porównawczego, postępuj zgodnie z obowiązującymi dla niego zasadami raportowania.

Reguły SPEC CPU 2017 wymagają pełnego ujawnienia warunków istotnych dla wydajności oraz wystarczającej ilości szczegółów konfiguracji, aby odtworzyć publiczny wynik. Jest to użyteczny standard nawet w przypadku testowania obciążenia wewnętrznego. Test porównawczy z pojedynczym, niewyjaśnionym wynikiem nie wystarcza, aby stwierdzić, czy wynik pochodzi z systemu operacyjnego, flag kompilatora, ustawień BIOS-u czy innego sprzętu.

Co jest znane, co zależy od konfiguracji, a co pozostaje niepotwierdzone?

• Znane: aktualna dokumentacja SLES 15 SP7 i RHEL 9 opisuje różne strumienie jądra i konfigurację wydajności opartą na TuneD. Obaj dostawcy dokumentują narzędzia do dostrajania pod kątem konkretnych obciążeń.
• Zależy to od środowiska: przepustowości, opóźnień, zużycia energii, czasu rozruchu, gęstości maszyn wirtualnych, zachowania sterownika i nakładu pracy wymaganego do utrzymania spójności ustawień. Różnią się one w zależności od sprzętu, aplikacji, wersji i polityki operacyjnej.
• Przeglądnięta dokumentacja nie potwierdziła, że: SLES 15 jest kategorycznie szybszy niż RHEL 9, RHEL 9 jest kategorycznie szybszy niż SLES 15 ani że jedna wersja bazowa jądra gwarantuje przewagę wydajnościową dla każdego obciążenia.

Wybierz dystrybucję, która spełnia Twoje wymagania dotyczące certyfikacji, wsparcia, cyklu życia i działania, a następnie zweryfikuj wydajność za pomocą kontrolowanego dowodu słuszności koncepcji. Jeśli zmierzona różnica jest mniejsza niż zmienność między uruchomieniami, potraktuj systemy jako równe dla tego obciążenia i podejmij decyzję, biorąc pod uwagę potrzeby w zakresie wsparcia, kompatybilności i administracji.

Oficjalne referencje

• SUSE: Przewodnik po analizie i dostrajaniu systemu SLES 15 SP7
• SUSE: Informacje o wydaniu SLES 15 SP7
• Red Hat: zarządzanie, monitorowanie i aktualizowanie jądra RHEL 9
• Red Hat: Wprowadzenie do TuneD w RHEL 9
• Red Hat: dostosowywanie profili TuneD
• SPEC: Zasady uruchamiania i raportowania procesora 2017
• SPEC: Przegląd procesorów CPU 2017 i zasady dozwolonego użytku