แกน CPU เพิ่มเติมเทียบกับดิสก์ที่เร็วกว่า

ฉันเป็นส่วนหนึ่งของ บริษัท ขนาดเล็กดังนั้นตามปกติจะครอบคลุมบทบาทที่แตกต่างกันจำนวนหนึ่ง ล่าสุดคือการจัดหากล่อง SQL Server เฉพาะสำหรับ. NET web app ของเรา เราได้รับการยกมาใน Dual Xeon E5-2620 (หกคอร์) การกำหนดค่าซีพียู 2.00 GHz (รวม 12 คอร์) พร้อม RAM 32 GB สิ่งนี้ทำให้เรามีงบประมาณ จำกัด สำหรับดิสก์อาเรย์ซึ่งโดยพื้นฐานแล้วจะประกอบด้วยไดรฟ์ SAS 300 GB 2.5 นิ้ว (15k RPM) สองตัวในการกำหนดค่า RAID 1

ฉันรู้ว่าการตั้งค่าดิสก์นั้นเหมาะสมที่สุดสำหรับ SQL Server และฉันต้องการผลักดัน RAID 10 จริงๆเพื่อให้เราสามารถวางฐานข้อมูลไฟล์บันทึกและ tempdb ลงในไดรฟ์ของตัวเอง เพื่อที่จะทำให้มันเข้ากันได้กับงบประมาณของเราฉันควรพิจารณาลดจำนวนคอร์ของ CPU หรือไม่ หรือฉันจะได้ธนาคารที่ดีกว่าสำหรับเจ้าชู้ที่รักษาแกนและใช้ไดรฟ์ให้น้อยลงบางทีอาจเป็น 4 ในการตั้งค่าแบบ RAID 1

นี่คือสถิติเพิ่มเติมบางส่วน

• ฐานข้อมูล SQL Server เอียงไปทางจำนวนการอ่านเพื่อเขียนสูงถึง 80% เทียบกับ 20% ตามลำดับ ขนาดฐานข้อมูลปัจจุบันอยู่ที่ประมาณ10 GB 26 GB ในปัจจุบันเติบโตในอัตรา 250 MB ต่อเดือน

• ปัจจุบันทำงานบน SQL Server 2008 R2 Standard บนกล่องสี่เหลี่ยม Xeon แกนเดียวที่ใช้ร่วมกันกับเว็บเซิร์ฟเวอร์ (12 GB Ram, ไดรฟ์ SAS 2 x 10k 300GB SAS ใน RAID 1) ต้องการย้ายไปยัง SQL Server 2012 Standard

• ฐานข้อมูลให้บริการผู้ใช้งานพร้อมกันประมาณ 100-150 คนพร้อมงานจัดตารางพื้นหลังบางส่วนอ่านนี้ฉันคิดว่า 12 คอร์คือ overkill ร้ายแรง!

ฉันปรับใช้แอปพลิเคชันทั้งหมดไปยังบริการคลาวด์ Azure (2 อินสแตนซ์ขนาดเล็ก) ที่เชื่อมโยงกับ SQL Azure DB แม้ว่าประสิทธิภาพจะสมเหตุสมผลเมื่อทำการทดสอบ (เกือบเป็นศูนย์โหลด) ฉันสูญเสียความกล้าที่จะใช้ในการผลิตเนื่องจากความคาดเดาไม่ได้ที่ฉันได้อ่านมามาก มันอาจทำงานได้ดีขึ้นด้วยวิธีการขยายขนาด แต่ด้วยฐานข้อมูลเพียง 10 GB ฉันอาจจะสามารถปรับขนาดได้ทันทีและประหยัดเงินได้

ตอนแรกฉันมองข้ามค่าใช้จ่ายในการออกใบอนุญาตและไม่ทราบว่าสิทธิ์ใช้งาน SQL Server 2012 นั้นขึ้นอยู่กับจำนวนของแกนประมวลผล ฉันมีการสมัครสมาชิก BizSpark MSDN พร้อมกับสิทธิ์ใช้งาน SQL Server 2012 Standard ดังนั้นฉันจำเป็นต้องอ่านจำนวนแกนที่จะใช้จากกล่อง

พูดจากประสบการณ์ที่เจียมเนื้อเจียมตัว แต่ฉันคิดว่าการแบ่งปันที่คุ้มค่าคอขวดที่สำคัญกับฐานข้อมูล SQL (Sybase และเซิร์ฟเวอร์ SQL ที่นี่) เป็นที่เก็บข้อมูล

แต่ฉันคิดว่ามันยุติธรรมเท่านั้นที่มีคนเปรียบเทียบการตั้งค่าของพวกเขาก่อนที่จะตัดสินใจผิด ๆ ในกรณีของฉันการใช้งาน CPU ไม่สูงขึ้นพอที่จะปรับการอัพเกรดซีพียูได้เร็ว ๆ นี้ ฉันได้อัปเกรดจากไดรฟ์เดียวเป็น RAID 1 แล้วเป็น RAID 10 + การชนจาก 8GB เป็น 16GB ของ RAM

การอัปเกรด RAID ทั้งหมดเหล่านี้ช่วยลดเวลารอคอยก่อนหน้าลงได้ 2 ถึง 6 เท่าฉันสงสัยว่าการอัปเกรดเป็น SSD จะดียิ่งขึ้น หากคุณคิดเกี่ยวกับมันจะสามารถลดแบนด์วิดธ์ (ทางทฤษฎี) ทั้งหมด ลิงก์ [(ความเร็ว RAM + ขนาด RAM + ตัวควบคุมหน่วยความจำ) ของคุณเชื่อมโยงไปยัง CPU] มีขีด จำกัด แบนด์วิดท์ซึ่งจะเป็นปัจจัยที่สำคัญที่สุดในการอ่านเมื่อข้อมูลของคุณควรถูกแคชเสมอ (RAID) ที่เก็บข้อมูลเฉพาะของคุณ ส่งผลต่อการอ่านเมื่อแคชไม่ได้รับและเขียนเมื่อมีการล้างข้อมูลหรือมีลูกค้าจำนวนมากที่เขียนข้อมูลจำนวนมากรวมกัน)

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

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

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

หลังจากการอัพเกรดที่ครอบคลุมมากขึ้นบนเซิร์ฟเวอร์มากกว่า 5 ตัวฉันกลับมาแชร์ประสบการณ์ของฉัน ฉันยังคงสนับสนุนการอัปเกรดที่เก็บข้อมูลครั้งแรกจากนั้น RAM และ CPU เหตุผลคือความไม่เท่าเทียมกันของแบนด์วิดท์ในระบบระหว่างหน่วยความจำ RAM และ CPU ตามลำดับต่ำสุดถึงสูงสุด ดังนั้นฉันจึงอัพเกรดเซิร์ฟเวอร์จำนวนมากจาก RAID10 และ RAID1 คู่เป็น SSD

วิธีที่ฉันทำเนื่องจากความกังวลด้านต้นทุน (ฉันมีเซิร์ฟเวอร์เพิ่มอีก 20 เครื่องสำหรับการอัปเกรด) คือการย้ายข้อมูลฐานข้อมูลและไฟล์วัตถุไปยัง SSD (ใช่เพียง SSD เดียวใน RAID0) และย้ายบันทึกธุรกรรมพร้อม tempdb ไปเป็น 4xHDD RAID10 องค์ประกอบ ฉันทดสอบกับ tempdb บน SSD ด้วยผลลัพธ์ที่ยอดเยี่ยม (อันที่จริงแล้วผลลัพธ์ที่ดีมากที่มีการสืบค้นได้เร็วกว่า 15 เท่าบางครั้งให้รายงานบางเรื่องโดยใช้เวลาไม่กี่วินาทีแทนที่จะเป็นนาทีที่ผ่านมา) แต่ภายหลังย้าย tempdb ไปยังดิสก์ RAID10 เพราะ ความกังวลเรื่องการสึกหรออย่างเข้มข้นสำหรับ SSD

ตอนนี้โดยทั่วไปฉันสังเกตเห็นเวลาตอบสนองที่เร็วขึ้น 10-15 ครั้งต่อหนึ่งข้อความค้นหาที่ยาวที่สุด SSD นั้นยอดเยี่ยมสำหรับการอ่านข้อมูลลงใน RAM อย่างรวดเร็วเนื่องจาก SQL Server ไม่ได้นำข้อมูลไปสู่ ​​RAM จนกว่าจะมีการร้องขอและแน่นอนว่าข้อมูลแรกจะต้องโหลดลงใน RAM เพื่อประมวลผลโดย CPU (ภายหลังในแคช L1, L2, L3) ดังนั้น SSD จึงช่วยลดระยะเวลารอคอยเริ่มต้นนั้นได้เป็นอย่างมาก และ SSD ยังช่วยลดเวลาในการแลกเปลี่ยน ... การล้าง RAM และโหลดข้อมูลใหม่โดยเฉพาะถ้าฐานข้อมูลของคุณมีขนาดใหญ่เกินกว่าจะใส่ลงใน RAM ได้

โดยรวมแล้วเรามีความยินดีเป็นอย่างยิ่งและได้รับการดำเนินการอย่างต่อเนื่องเป็นเวลาหลายเดือนในกระบวนการโยกย้ายที่ช้าเพื่ออนุญาตให้เซิร์ฟเวอร์ทำงานเพื่อให้ฉันสามารถรวบรวมข้อมูลระดับการสวมใส่ก่อนที่ฉันจะเปลี่ยนเซิร์ฟเวอร์ทั้งหมดเป็นการกำหนดค่านี้ และนี่เป็นเพียง SQL Server Express! : D - ตรวจสอบให้แน่ใจว่า SSD ของคุณสามารถให้บริการ IOPS คงที่เพราะนั่นเป็นอีกสิ่งหนึ่งที่สร้างความแตกต่างอย่างมาก (เพียงแค่ google มัน) นั่นเป็นเหตุผลที่ฉันเลือก Intel DC (DataCenter) SSDs series

ไม่ใช่คำตอบที่คุณอาจมองหาในส่วนแรก แต่: คุณเคยคิดที่จะผลักดันมันไปสู่เมฆหรือไม่? AWS ช่วยให้คุณสามารถจัดหาความต้องการส่วนใหญ่ข้างต้นและเพิ่มกำลังซื้อของคุณโดยไม่ต้องจัดการกับฮาร์ดแวร์เช่นกัน

ส่วนที่สอง - ฮาร์ดแวร์ขึ้นอยู่กับงานจริงๆ ฉันมักจะพึ่งพา CPU มากขึ้นเมื่อฉันสามารถรวม CLR แบบกำหนดเองได้เพราะฉันสามารถปรับให้เหมาะสมสำหรับการแก้ปัญหาแบบขนานจริง ๆ ส่วนใหญ่เวลาถ้ามันจะดีกว่าที่จะได้ตั้งโซลูชั่นตามฉันพบว่า RAM และความเร็วฮาร์ดไดรฟ์เป็นคอขวดที่ใหญ่ที่สุดและที่สองน่าจะเป็นกรณีของคุณ (ที่แนวคิด SSD ข้างต้นจะเป็นประโยชน์)

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