การประมาณความต้องการ IO สำหรับการใช้งาน Bursty


11

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

สำหรับระบบที่มีประสบการณ์การใช้งานค่อนข้างคงที่ฉันเคยได้ยินกฏเกณฑ์ง่าย ๆ ในการสังเกตความยาวคิวของดิสก์และเก็บหมายเลขนั้นไว้ค่อนข้างน้อย สิ่งนี้จะทำงานเป็นพิเศษใน AWS โดยที่ฉันได้เห็นกฎของหัวแม่มือว่าความยาวคิวดิสก์ 1 ต่อ 100 IOPS นั้นสมเหตุสมผล

ฉันจะประเมินข้อกำหนดของ IO สำหรับระบบดังกล่าวได้อย่างไร ความยาวคิวของดิสก์เป็นตัวบ่งชี้ที่เชื่อถือได้เมื่อต้องจัดการกับข้อความค้นหาแต่ละรายการหรือไม่ มีตัวชี้วัดอื่นที่ฉันควรพิจารณาหรือไม่


มีการเขียนใด ๆ เกิดขึ้นหรือนี่เป็นงานหนักหรือ?
แจ็คบอกว่าลอง topanswers.xyz

@JackDouglas: นี่คือ 98% อ่าน มีหยดของการเขียนเป็น
Eric J.

1
คำถามถัดไป: มีการอ่านกระจัดกระจายหรือ "คำขอส่วนบุคคลสำหรับข้อมูลจำนวนมาก" ของคุณน่าจะทำตามลำดับ IO หรือไม่
แจ็คบอกว่าลอง topanswers.xyz

@JackDouglas: การอ่านที่ใหญ่ที่สุดคือผ่านมุมมองที่จัดทำดัชนีเช่น WHERE clause ที่สอดคล้องกับดัชนี แต่ส่งคืนข้อมูลมากกว่าที่เป็นอยู่ในดัชนี ฉันไม่แน่ใจว่าสิ่งนั้นหมายถึงระดับของลำดับ IO เนื่องจากระบบย่อย IO พื้นฐานคือ AWS EBS ฉันไม่แน่ใจว่าจะส่งผลต่อการเข้าถึงทางกายภาพอย่างไร
Eric J.

ระบบย่อย IO พื้นฐานจะส่งผลต่อความสอดคล้องของประสิทธิภาพแต่จะดูแลเกี่ยวกับการเข้าถึงลำดับ v กระจัดกระจายในลักษณะที่คล้ายคลึงกับที่เก็บข้อมูลในเครื่อง คนจำนวนมากอ่านบล็อกที่แตกต่างกันจำนวนมาก การสแกนดัชนีจะเรียงตามลำดับ แต่การเข้าถึงตารางจะไม่เป็นถ้าฉันเข้าใจคุณอย่างถูกต้องจนถึงตอนนี้
แจ็คบอกว่าลอง topanswers.xyz

คำตอบ:


10

ตัวชี้วัดหลักที่ฉันพิจารณาเสมอสำหรับ IO ใน SQL Server ไม่ใช่ IOPs หรือ Disk Queue Length แต่ปริมาณงานของดิสก์ (วินาที / อ่านและวินาที / เขียน) โดยรวมแล้วฐานข้อมูลไม่ได้เกี่ยวกับจำนวนการดำเนินการที่คุณสามารถส่งไปยังดิสก์ได้ กฎทั่วไปของหัวแม่มือคือมีน้อยกว่า 20ms / การดำเนินงาน (แม้ว่าต่ำกว่าดีกว่าเสมอ) รายละเอียดเพิ่มเติมสามารถพบได้ในบทความนี้

Disk Queue Length เป็นสถิติปลอมและไม่เกี่ยวข้องกันอีกต่อไป ปัญหาก็คือว่าค่าวัดคิวสำหรับไดรฟ์เดียว แต่ตอนนี้เราอยู่ในยุคของ RAIDs, SAN และหน่วยความจำแบบกระจายอื่น ๆ ไม่มีทางที่จะแปลค่านี้เป็นตัวเลขที่มีความหมายได้อย่างถูกต้อง จุดเริ่มต้นที่ยอดเยี่ยมสำหรับการวัดประสิทธิภาพคือโปสเตอร์จาก Quest / Dellที่ให้ข้อมูลและคำอธิบายมากมายแก่คุณว่าทำไมพวกเขาถึงมีความสำคัญ คุณไม่จำเป็นต้องใช้ทั้งหมด แต่เป็นการเริ่มต้น

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

ในที่สุด, หมายเหตุเกี่ยวกับ AWS: สำหรับความรู้ของฉัน, Amazon จะไม่รับประกันประสิทธิภาพของ IO ใน AWS นี่เป็นหลักเนื่องจากที่เก็บข้อมูลเป็นทรัพยากรที่ใช้ร่วมกันขนาดใหญ่และเป็นไปไม่ได้ที่จะวัดรูปแบบของคุณและเพื่อนบ้านของคุณในพื้นที่จัดเก็บเฉพาะ (ดูปัญหาที่รบกวนเพื่อนบ้าน )

คำแนะนำของฉันจะจัดสรรหน่วยความจำให้มากที่สุด SQL Server จะผลักหน่วยความจำออกจากหน่วยความจำหากอยู่ภายใต้แรงกดดันและพื้นที่ในบัฟเฟอร์พูล (ขึ้นอยู่กับ LRU-K) ดังนั้นหากคุณบัฟเฟอร์พูลสามารถจัดเก็บฐานข้อมูลส่วนใหญ่ในหน่วยความจำคุณสามารถลดประสิทธิภาพการทำงานบางส่วนได้ นอกจากนี้ให้พิจารณากลยุทธ์ที่สามารถทำให้วัตถุแคช "อุ่น" สุดท้ายจับตาดู SQL 2014 และคุณลักษณะใหม่ของHekaton


"SQL Server จะผลักหน่วยความจำออกจากหน่วยความจำเท่านั้นหากอยู่ภายใต้แรงกดดัน" หรือที่จุดตรวจ ?
แจ็คพูดว่าลอง topanswers.xyz

5
จุดตรวจไม่ได้ลบวัตถุออกจากบัฟเฟอร์ แต่เขียนหน้าสกปรกไปยังดิสก์เพื่อการกู้คืน มันจะยังคงรักษาวัตถุในบัฟเฟอร์พูลไว้
Mike Fal

ขอบคุณสำหรับคำตอบโดยละเอียด ตอนนี้ AWS มีคุณสมบัติพิเศษที่เรียกว่า IOPS ที่จัดสรรไว้เพื่อให้แน่ใจว่าสามารถทำการดำเนินการ IO ต่อวินาทีที่ซื้อได้จำนวน 99.9% ของเวลา ฉันคิดว่าการใช้งาน IO นั้นหมายถึงการอ่านหรือการเขียนบล็อกข้อมูลขนาด 16K
Eric J.

@MikeFal: คุณมีความคิดเกี่ยวกับวิธีการทดสอบโดยเฉพาะสำหรับรูปแบบการระเบิดนี้หรือไม่? เพียงเรียกใช้แบบสอบถามเดียวและดูเคาน์เตอร์ที่มีปัญหา? เรียกใช้แบบสอบถามจำนวนหนึ่ง (ปกติเป็นระยะ) หลังจากดูอีกหนึ่งตัวนับดูหรือไม่
Eric J.

ใช่ฉันคุ้นเคยกับ PIOPS ในขณะที่ฉันระบุฉันไม่ต้องการทราบจำนวนการดำเนินการที่สามารถดำเนินการได้ฉันต้องการทราบว่าการดำเนินการรวดเร็วแค่ไหน และนี่ไม่ใช่สิ่งที่ AWS รับประกันได้แม้แต่ใน PIOPs
Mike Fal
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.