SLES 15 เทียบกับ RHEL 9: การเปรียบเทียบประสิทธิภาพของเซิร์ฟเวอร์ระดับองค์กร

ไม่มีระบบปฏิบัติการใดที่เหนือกว่ากันอย่างเด็ดขาดในด้านประสิทธิภาพระหว่าง SUSE Linux Enterprise Server 15 และ Red Hat Enterprise Linux 9คำตอบที่สมเหตุสมผลขึ้นอยู่กับ Service Pack หรือ Minor Release ที่ใช้ ฮาร์ดแวร์ การอัปเดตเคอร์เนล โปรไฟล์การปรับแต่ง ชุดแอปพลิเคชัน และปริมาณงาน คู่มือการปรับแต่ง SUSE SLES 15 SP7 ในปัจจุบันและเอกสาร RHEL 9 ของ Red Hat อธิบายถึงความสามารถในการปรับแต่ง แต่ไม่ได้ระบุผลการเปรียบเทียบความเร็วแบบทั่วไปที่ควบคุมได้

ความแตกต่างนี้มีความสำคัญ เพราะเอกสารของ 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 อธิบายถึงคำแนะนำโปรไฟล์ตามการกำหนดค่าระบบ เอกสาร RHEL 9 ของ Red Hat ก็ระบุว่าการเลือกโปรไฟล์อัตโนมัติขึ้นอยู่กับประเภทเครื่องและการตั้งค่าระบบ แม้ว่าทั้งสองโฮสต์จะรายงานโปรไฟล์ที่มีชื่อเดียวกันก็ตาม ให้ตรวจสอบว่าโปรไฟล์นั้นเปลี่ยนแปลงอะไรบ้างก่อนที่จะถือว่าการกำหนดค่าเหมือนกัน

ขั้นตอน:รัน โปรแกรม sudo tuned-adm activeบนsudo tuned-adm listแต่ละโฮสต์ บันทึกผลลัพธ์และไฟล์โปรไฟล์ที่กำหนดเอง สำหรับการเปรียบเทียบ "การติดตั้งแบบค่าเริ่มต้น" ให้คงค่าเริ่มต้นที่ผู้จำหน่ายแต่ละรายรองรับไว้และบันทึกไว้ สำหรับการเปรียบเทียบ "ประสิทธิภาพที่ดีที่สุดที่สามารถทำได้" ให้ปรับแต่งระบบปฏิบัติการแต่ละระบบแยกกันโดยใช้คำแนะนำของผู้จำหน่าย จากนั้นรายงานโปรไฟล์และการตั้งค่าที่ใช้

อย่าใช้โปรไฟล์ประสิทธิภาพทุกอันพร้อมกัน โปรไฟล์อาจขัดแย้งกันได้ ตัวอย่างเช่น การตั้งค่าการจัดเก็บข้อมูลที่เน้นปริมาณงานอาจถูกบั่นทอนโดยการตั้งค่าอื่นที่เพิ่มอัตราการหยุดหมุนของดิสก์ เปลี่ยนตัวแปรที่เกี่ยวข้องทีละตัว ตรวจสอบให้แน่ใจว่าบริการยังคงเสถียร และเก็บบันทึกการย้อนกลับไว้ด้วย

ระบบใดมีแนวโน้มที่จะทำงานได้ดีกว่าสำหรับปริมาณงานของคุณ?

ปริมาณงานมักมีความสำคัญมากกว่าฉลากการจัดจำหน่ายในวงกว้าง นี่คือลำดับความสำคัญในการทดสอบ ไม่ใช่คำมั่นสัญญาว่าผู้ขายรายใดจะเป็นผู้ชนะ:

• แอปพลิเคชันที่ใช้ CPU เป็นหลัก:ใช้คอมไพเลอร์ รันไทม์ ไลบรารี และการตั้งค่าความปลอดภัยเวอร์ชันใช้งานจริง วัดปริมาณงานที่เสร็จสมบูรณ์ต่อวินาทีและเวลา CPU การทดสอบประสิทธิภาพระดับไมโครสามารถช่วยอธิบายความแตกต่างได้ แต่ไม่สามารถทดแทนการทดสอบแอปพลิเคชันได้
• ฐานข้อมูลและบริการที่ใช้หน่วยความจำมาก:ควรใช้เวอร์ชันฐานข้อมูล โครงสร้างข้อมูล ขนาดชุดข้อมูลที่ใช้งาน การทำงานพร้อมกัน และนโยบายการคงอยู่ของข้อมูลที่เหมาะสม ติดตามจำนวนธุรกรรมต่อวินาทีควบคู่ไปกับค่ามัธยฐานและค่าความหน่วงต่ำสุด อัตราเฉลี่ยที่สูงอาจปกปิดคำขอที่ช้ากว่าได้
• บริการที่ใช้พื้นที่จัดเก็บข้อมูลมาก:ควรใช้ไดรฟ์รุ่นเดียวกัน เฟิร์มแวร์คอนโทรลเลอร์ ระบบไฟล์ ตัวเลือกการเมานต์ ชุดข้อมูล และความลึกของคิวแบบเดียวกัน วัดสัดส่วนการอ่าน/เขียนและการกระจายความหน่วงที่เกิดขึ้นจริง ไม่ใช่แค่ปริมาณงานต่อเนื่องสูงสุดเท่านั้น
• บริการเครือข่าย:รักษาค่า NIC, เฟิร์มแวร์, เส้นทางสวิตช์, MTU, การตั้งค่าการถ่ายโอนข้อมูล และปริมาณงานของไคลเอ็นต์ให้สม่ำเสมอ วัดปริมาณงานและเวลาแฝงของแอปพลิเคชันภายใต้จำนวนการเชื่อมต่อที่คาดการณ์ไว้
• เครื่องเสมือนหรือคอนเทนเนอร์:เปรียบเทียบโดยใช้ไฮเปอร์ไวเซอร์หรือสแต็กคอนเทนเนอร์เดียวกัน มีการจัดสรร CPU และหน่วยความจำเหมือนกัน นโยบายโฮสต์ โปรไฟล์แขก และอิมเมจเดียวกัน รวมทั้งความหนาแน่นและการแย่งชิงทรัพยากรหากสะท้อนถึงสภาพแวดล้อมการใช้งานจริง
• ระบบที่ไวต่อพลังงาน:ควรรายงานพลังงานต่อหน่วยงานที่เสร็จสมบูรณ์ ไม่ใช่แค่ความเร็วสูงสุด ระบบที่ใช้พลังงานน้อยลงแต่ใช้เวลานานขึ้น อาจไม่ได้ใช้พลังงานรวมน้อยลงสำหรับงานแบบกลุ่มเสมอไป

หากคุณไม่ทราบว่าเวลาหมดไปกับอะไรบ้าง ให้ทำการวิเคราะห์ประสิทธิภาพของแอปพลิเคชัน หรือตรวจสอบการใช้งาน CPU, แรงดันหน่วยความจำ, การรอ I/O, ความอิ่มตัวของเครือข่าย และคิวการทำงานก่อนที่จะทำการปรับแต่ง มิเช่นนั้น การเพิ่มประสิทธิภาพ CPU ก็จะไม่สามารถแก้ไขปัญหาคอขวดด้านการจัดเก็บข้อมูลได้

คุณควรทำการเปรียบเทียบอย่างยุติธรรมอย่างไร?

ก่อนอื่นให้ตัดสินใจว่าคุณกำลังตอบคำถามอะไร “ระบบใดเร็วกว่ากันทันทีหลังการติดตั้ง?” แตกต่างจาก “ระบบใดเร็วกว่ากันหลังจากปรับแต่งเพื่อใช้งานจริง?” อย่าเปรียบเทียบการตั้งค่าที่ปรับแต่งแล้วของระบบปฏิบัติการหนึ่งกับการตั้งค่าเริ่มต้นของอีกระบบปฏิบัติการหนึ่ง แล้วเรียกผลลัพธ์นั้นว่าเป็นการเปรียบเทียบระบบปฏิบัติการ

1. เลือกใช้แพลตฟอร์มที่เหมือนกัน:ควรใช้เซิร์ฟเวอร์รุ่นที่เหมือนกันทุกประการ เช่น ซีพียูรุ่นเดียวกัน หน่วยความจำเท่ากัน BIOS/เฟิร์มแวร์เท่ากัน พื้นที่จัดเก็บข้อมูลเท่ากัน การ์ดเครือข่ายเท่ากัน และข้อจำกัดด้านพลังงานเท่ากัน
2. บันทึกรายละเอียดซอฟต์แวร์:จดบันทึก Service Pack และระดับการอัปเดตของ SLES, Minor Release และระดับการอัปเดตของ RHEL, แพ็คเกจเคอร์เนล, เวอร์ชันแอปพลิเคชัน, รันไทม์/คอมไพเลอร์, เฟิร์มแวร์ และมาตรการรักษาความปลอดภัยที่เกี่ยวข้อง
3. การกำหนดค่าการควบคุม:บันทึกโปรไฟล์ TuneD, ตัวควบคุม CPU หรือโหมดพลังงาน, การตั้งค่า NUMA และ huge-page, ตัวเลือกไฟล์ระบบและการเมานต์ และพารามิเตอร์แอปพลิเคชัน ใช้ค่าเริ่มต้นสำหรับการทดสอบแบบไม่ต้องปรับแต่ง หรือปรับแต่งทั้งสองระบบโดยตั้งใจเพื่อการทดสอบที่เหมาะสมที่สุด
4. ใช้ข้อมูลและการโหลดที่เหมือนกับการใช้งานจริง:ทำการทดสอบให้นานพอที่จะได้พฤติกรรมที่คงที่ และรวมถึงการทำงานพร้อมกันและขนาดข้อมูลที่สำคัญ กำหนดสถานะแคชและขั้นตอนการวอร์มอัพเพื่อให้การทดสอบแต่ละครั้งเริ่มต้นได้อย่างเทียบเคียงกันได้
5. ทำการทดสอบซ้ำและรายงานความแปรปรวน:สลับลำดับการทดสอบเมื่อเป็นไปได้ ทำการทดสอบซ้ำ และแสดงค่ามัธยฐานพร้อมกับความแปรปรวนระหว่างการทดสอบแต่ละครั้ง รายงานปริมาณงานพร้อมกับค่าความหน่วง p95/p99 การใช้ทรัพยากร และข้อผิดพลาดที่เกี่ยวข้อง
6. จัดทำบันทึกที่สามารถตรวจสอบซ้ำได้:เผยแพร่การกำหนดค่าระบบ เวอร์ชันของเกณฑ์มาตรฐาน คำสั่งหรือสคริปต์ ความแตกต่างในการปรับแต่ง และผลลัพธ์ดิบ หากผลลัพธ์นั้นมาจากเกณฑ์มาตรฐานสาธารณะ ให้ปฏิบัติตามกฎการรายงานปัจจุบันของเกณฑ์มาตรฐานนั้น

กฎของ SPEC CPU 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
• SPEC: กฎการทำงานและการรายงานของ CPU 2017
• รายละเอียด: ภาพรวม CPU ปี 2017 และหลักการใช้งานอย่างเป็นธรรม