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. 출력 결과와 사용자 지정 프로필 파일을 저장합니다. "기본 설치" 비교를 위해서는 각 공급업체에서 지원하는 기본 설정을 유지하고 문서화합니다. "최적 성능" 비교를 위해서는 각 운영 체제를 공급업체의 지침에 따라 개별적으로 튜닝한 후 사용한 프로필과 설정을 보고합니다.

모든 성능 프로필을 한 번에 적용하지 마십시오. 프로필 간에 충돌이 발생할 수 있습니다. 예를 들어, 처리량 중심의 스토리지 설정이 디스크 회전 속도를 높이는 다른 설정에 의해 상쇄될 수 있습니다. 관련 변수를 한 번에 하나씩 변경하고 서비스가 안정적으로 유지되는지 확인한 후 롤백 기록을 보관하십시오.

어떤 시스템이 작업 부하에 더 적합할까요?

일반적으로 작업량은 광범위한 유통 브랜드보다 더 중요합니다. 이는 테스트 우선순위이지, 어느 공급업체가 승리할지에 대한 약속이 아닙니다.

• CPU 사용량이 많은 애플리케이션의 경우, 실제 운영 체제에서 사용하는 컴파일러, 런타임, 라이브러리 및 보안 설정을 활용하십시오. 초당 완료된 작업량과 CPU 시간을 측정하십시오. 마이크로벤치마크는 차이점을 설명하는 데 도움이 될 수 있지만, 실제 애플리케이션 테스트를 대체할 수는 없습니다.
• 데이터베이스 및 메모리 집약적인 서비스: 대표적인 데이터베이스 버전, 스키마, 작업 세트 크기, 동시성 및 영구 저장 정책을 사용하십시오. 초당 트랜잭션 수와 중앙값 및 꼬리 지연 시간을 추적하십시오. 평균 처리량이 높으면 느린 요청이 숨겨질 수 있습니다.
• 저장 용량이 큰 서비스의 경우 , 드라이브 모델, 컨트롤러 펌웨어, 파일 시스템, 마운트 옵션, 데이터 세트 및 큐 깊이를 동일하게 유지하십시오. 최대 순차 처리량뿐만 아니라 실제 읽기/쓰기 비율과 지연 시간 분포를 측정하십시오.
• 네트워크 서비스: NIC, 펌웨어, 스위치 경로, MTU, 오프로드 설정 및 클라이언트 부하를 일정하게 유지합니다. 예상 연결 수에서 애플리케이션 처리량과 지연 시간을 측정합니다.
• 가상 머신 또는 컨테이너: 동일한 하이퍼바이저 또는 컨테이너 스택, 동일한 CPU 및 메모리 할당, 호스트 정책, 게스트 프로필 및 이미지를 사용하여 비교하십시오. 프로덕션 환경을 반영하는 경우 밀도 및 리소스 경합도 포함하십시오.
• 전력 소모에 민감한 시스템은 최고 속도뿐만 아니라 완료된 작업 단위당 에너지 소비량을 보고해야 합니다. 작업 시간이 더 오래 걸리더라도 전력 소모량이 적은 시스템이라고 해서 일괄 처리 작업 전체에 필요한 총 에너지 소비량이 더 적은 것은 아닙니다.

시간이 어떻게 흘러가는지 알 수 없다면, 튜닝 전에 애플리케이션 프로파일링을 하거나 CPU 사용량, 메모리 사용량, I/O 대기 시간, 네트워크 포화도, 실행 대기열 등을 모니터링하세요. 그렇지 않으면 더 빠른 CPU 프로파일링만으로는 스토리지 병목 현상을 해결할 수 없습니다.

공정한 비교를 하려면 어떻게 해야 할까요?

먼저 어떤 질문에 대한 답을 찾고 있는지 명확히 하세요. "설치 직후 어느 시스템이 더 빠른가?"와 "지원되는 운영 환경 튜닝 후 어느 시스템이 더 빠른가?"는 서로 다른 질문입니다. 한 배포판의 튜닝된 구성을 다른 배포판의 기본 설정과 비교하여 그 결과를 운영 체제 비교라고 부르지 마세요.

1. 플랫폼을 일치시키십시오. 가능한 한 동일한 CPU 스테핑, 메모리 구성, BIOS/펌웨어, 스토리지, NIC 및 전력 제한을 갖춘 동일한 서버 모델을 사용하십시오.
2. 소프트웨어 세부 정보를 기록해 두십시오. SLES 서비스 팩 및 업데이트 수준, RHEL 마이너 릴리스 및 업데이트 수준, 커널 패키지, 애플리케이션 버전, 런타임/컴파일러, 펌웨어 및 관련 보안 완화 조치를 기록해 두십시오.
3. 제어 구성: TuneD 프로파일, CPU 거버너 또는 전원 모드, NUMA 및 대용량 페이지 설정, 파일 시스템 및 마운트 옵션, 애플리케이션 매개변수를 기록합니다. 기본 설정으로 유지하여 바로 테스트를 진행하거나, 최적화된 테스트를 위해 두 시스템 모두 의도적으로 튜닝할 수 있습니다.
4. 실제 운영 환경과 유사한 데이터와 부하를 사용하세요. 안정적인 동작이 나타날 때까지 테스트 시간을 충분히 확보하고, 중요한 동시 접속 수와 데이터 크기를 포함시키세요. 각 실행이 유사한 환경에서 시작될 수 있도록 캐시 상태와 워밍업 절차를 정의하세요.
5. 반복 및 변동 보고: 가능한 경우 테스트 순서를 바꾸고, 실행을 반복하며, 중앙값과 실행 간 편차를 표시하십시오. 처리량, p95/p99 지연 시간, 리소스 소비량 및 관련 오류율을 함께 보고하십시오.
6. 재현 가능한 기록을 유지하십시오. 시스템 구성, 벤치마크 버전, 명령 또는 스크립트, 튜닝 차이점 및 원시 결과를 게시하십시오. 결과가 공개된 표준 벤치마크에 대한 것이라면 해당 벤치마크의 최신 보고 규칙을 따르십시오.

SPEC의 CPU 2017 규정은 성능 관련 조건에 대한 완전한 공개와 공개 결과를 재현할 수 있는 충분한 구성 세부 정보를 요구합니다. 이는 내부 워크로드를 테스트할 때에도 유용한 기준입니다. 설명이 부족한 단일 점수만으로는 결과가 운영 체제, 컴파일러 플래그, BIOS 설정 또는 다른 하드웨어에서 비롯된 것인지 판단하기에 충분하지 않습니다.

알려진 사실은 무엇이고, 설정에 따라 달라지는 것은 무엇이며, 아직 입증되지 않은 것은 무엇입니까?

• 알려진 사실: 현재 SLES 15 SP7 및 RHEL 9 문서에는 서로 다른 커널 스트림과 TuneD 기반 성능 구성에 대한 내용이 설명되어 있습니다. 두 공급업체 모두 워크로드별 튜닝 도구를 제공합니다.
• 환경에 따라 다릅니다. 처리량, 지연 시간, 전력 사용량, 부팅 시간, VM 밀도, 드라이버 동작, 그리고 튜닝을 일관되게 유지하는 데 필요한 노력 등이 모두 달라집니다. 이러한 요소들은 하드웨어, 애플리케이션, 릴리스 버전 및 운영 정책에 따라 변동합니다.
• 검토된 문서에서는 SLES 15가 RHEL 9보다 무조건 빠르다는 것, RHEL 9가 SLES 15보다 무조건 빠르다는 것, 또는 특정 커널 기반 버전이 모든 워크로드에서 성능 우위를 보장한다는 사실이 입증되지 않았습니다.

인증, 지원, 수명 주기 및 운영 요구 사항을 충족하는 배포판을 선택한 다음, 제어된 개념 증명을 통해 성능을 검증하십시오. 측정된 차이가 실행 간 변동보다 작으면 해당 워크로드에 대해 두 시스템을 동등하게 간주하고 지원 가능성, 호환성 및 관리 요구 사항을 기준으로 결정하십시오.

공식 참고 자료

• SUSE: SLES 15 SP7 시스템 분석 및 튜닝 가이드
• SUSE: SLES 15 SP7 릴리스 노트
• Red Hat: RHEL 9 커널 관리, 모니터링 및 업데이트
• Red Hat: RHEL 9에서 TuneD 시작하기
• Red Hat: TuneD 프로필 사용자 지정
• 사양: CPU 2017 실행 및 보고 규칙
• 사양: CPU 2017 개요 및 공정 사용