ฉันจะตอบในสองส่วนแรก: "ทำไมคำตอบแบบดั้งเดิมเกี่ยวกับการแยกตามลำดับและการสุ่มมักใช้ไม่ได้"
จากนั้นฉันจะพูดถึงประโยชน์ที่อาจเกิดขึ้นจากการแยกไฟล์ที่ Windows physicaldisk และเพื่อเพิ่ม vHBAs เพิ่มเติมและกระจายฟิสิคัลดิสก์ในหมู่พวกเขา
การคาดหวังประโยชน์จากการแยกดิสก์ IO และลำดับแบบสุ่มที่ระดับฟิสิคัลดิสก์ของ Windows โดยทั่วไปถือว่าอุปกรณ์ HDD สำหรับการจัดเก็บข้อมูล นอกจากนี้โดยทั่วไปถือว่า Windows ทางกายภาพแยกกันหมายถึงอุปกรณ์ HDD ที่แยก แนวคิดคือ HDD บางชุดกำลังจัดการดิสก์ตามลำดับ IO และมีการเคลื่อนไหวของหัวดิสก์ที่ จำกัด มาก (เช่น HDD ที่โฮสต์ txlog ไม่ว่าง *) ในขณะที่ HDD ชุดแยกต่างหากกำลังจัดการดิสก์ IO แบบสุ่ม
สมมติฐานเหล่านั้นไม่ค่อยมีในปัจจุบันโดยเฉพาะใน VM ก่อนอื่นเว้นแต่ว่าฟิสิคัล VMs Windows เป็น RDM หลายแห่งอาจอยู่ในที่เก็บข้อมูลเดียวหรืออาจเก็บหลายฐานข้อมูลอยู่ใน ESXi host LUN เดียว ดังนั้นสิ่งที่ถูกแยกออกจากผู้เยี่ยมชมสามารถรวมกันได้ในระดับโฮสต์ ESXi
แต่สมมติว่ามีการใช้ RDM หรือแต่ละดิสก์กายภาพแขกอยู่ในที่เก็บข้อมูลของตนเองใน ESXi LUN ของตัวเอง ถึงอย่างนั้นแยกลำดับจาก io แบบสุ่มในเกสต์ก็มักจะรวมกันที่อาเรย์เนื่องจาก LUNs ที่นำเสนอไปยังโฮสต์ ESXi อาจมาจากแหล่งเดียวของอุปกรณ์ดิสก์ เกือบทุกหน่วยเก็บข้อมูลทำเช่นนี้ในตอนนี้ - เฉพาะหรือเป็นตัวเลือกเพื่อความสะดวกในการจัดการและเพิ่มประสิทธิภาพการใช้ทรัพยากร
ในที่สุดการจัดเก็บข้อมูลจำนวนมากในวันนี้คือแฟลชหรือไฮบริดแฟลช + HDD ทั้งหมด เมื่อไม่มีการเคลื่อนไหวของหัวที่ต้องกังวลแฟลชจะไม่แคร์เรื่องการแยกลำดับสำหรับการสุ่ม ... ไม่สนใจเกี่ยวกับการทอผ้า IO
ดังนั้น…นี่คือเหตุผลทั้งหมดที่แยกการเรียงลำดับจากการสุ่มอาจไม่ทั้งหมดที่เป็นประโยชน์ ถัดไปทำไมการกระจายไฟล์ข้ามฟิสิคัลดิสก์และการกระจายฟิสิคัลดิสก์ข้าม vHBAs ยังสามารถเพิ่มประสิทธิภาพได้
* ฉันตั้งใจพูดถึงบันทึกการทำธุรกรรมเดียวในตัวอย่าง HDD นี้ เมื่อแยกดิสก์ IO ตามลำดับหลาย ๆ กระแส (เช่น 8 บันทึกธุรกรรมที่ไม่ว่าง) เกิดขึ้นบน HDD เดียวกัน - เว้นแต่กิจกรรมเกือบทั้งหมดจะอยู่ในแคช SAN - การเคลื่อนไหวส่วนหัวที่คงที่ในแทร็ก IO ต่อเนื่องนำไปสู่การทอผ้า IO นั่นเป็นประเภทของหัวดิสก์ที่เฉพาะเจาะจงซึ่งทำให้เกิดความล่าช้าของดิสก์ที่ "แย่กว่าการสุ่ม" เกิดขึ้นกับ RAID5 และ RAID10 แม้ว่า RAID10 สามารถทนต่อการเปลี่ยนแปลงเล็กน้อยในเรื่องนี้ได้มากกว่า RAID5 ก่อนที่จะเสื่อมโทรมอย่างมีนัยสำคัญ
ตอนนี้ - เนื่องจากการพูดคุยแบบยาวเกี่ยวกับการแยกลำดับจากการสุ่มอาจไม่ช่วยได้อย่างไร - การกระจายไฟล์ข้ามฟิสิคัลดิสก์ยังคงช่วยได้อย่างไร? การกระจายฟิสิคัลฟิสิคัลใน vHBAs ช่วยได้อย่างไร?
มันเกี่ยวกับคิว IO ของดิสก์
ฟิสิคัลดิสก์ Windows หรือ LogicalDisk ใด ๆ สามารถมีดิสก์ IO ที่ค้างได้สูงสุด 255 รายการในแต่ละครั้งโดย perfmon รายงานว่า "Current Disk Queue" จากดิสก์ IO ที่ค้างอยู่ในคิว physicaldisk สต็อคพอร์ทสามารถส่งผ่านสูงสุด 254 ไปยัง minidriver แต่ minidriver อาจมีทั้งคิวบริการ (ส่งผ่านไปยังระดับที่ต่ำกว่าถัดไป) และคิวรอ และสามารถแจ้งให้ storport ลดจำนวนที่ส่งผ่านจาก 254
ในเกสต์ VMware Windows ไดรเวอร์ pvscsi มี "อุปกรณ์" คิวเริ่มต้นที่ 64 ซึ่งอุปกรณ์เป็นฟิสิคัลดิสก์ ดังนั้นแม้ว่า perfmon สามารถแสดงดิสก์ IO ได้มากถึง 255 รายการใน "ความยาวคิวดิสก์ปัจจุบัน" สำหรับฟิสิคัลดิสก์เดียว แต่จะมีเพียง 64 รายการเท่านั้นที่จะถูกส่งไปยังระดับถัดไปในแต่ละครั้ง (เว้นแต่จะมีการเปลี่ยนแปลงค่าเริ่มต้น)
ดิสก์ IO จำนวนสามารถโดดเด่นหนึ่งบันทึกธุรกรรมไม่ว่างในเวลา? การบันทึกธุรกรรมอาจมีขนาดสูงสุดถึง 60kb ในช่วง ETL ระดับสูงฉันมักจะเห็นทุกการเขียนไปยัง txlog ที่ 60kb ผู้เขียน txlog สามารถเขียนได้มากถึง 32 การเขียนที่ยอดเยี่ยม 60kb ต่อการบันทึกทีเอ็กซ์ล็อกหนึ่งครั้ง ดังนั้นถ้าฉันมี txlog ที่ใช้งานไม่ว่างและ dw txlog ที่ไม่ว่างบน physicaldisk เดียวกันโดยมีการตั้งค่า VMware เริ่มต้น ถ้าทั้งสอง txlogs มีค่าสูงสุดที่ 32 60kb ที่ยอดเยี่ยมเขียนแต่ละอัน physicaldisk นั้นอยู่ที่ความลึกของคิว 64 ตอนนี้…จะเป็นยังไงถ้ามีไฟล์ flatfiles เป็น ETL บน physicaldisk ล่ะ? อืม…ระหว่างการอ่าน flatfiles กับการเขียน txlog พวกเขาจะต้องใช้คิวการรอเพราะมีเพียง 64 คนเท่านั้นที่สามารถออกได้ในแต่ละครั้ง สำหรับฐานข้อมูลที่มี txlogs ไม่ว่างเช่นนั้นไม่ว่าจะเป็นเซิร์ฟเวอร์จริงหรือเสมือนฉันแนะนำ txlog บน physicaldisk ของตัวเอง ไม่มีสิ่งอื่นใดในฟิสิคัลดิสก์ ที่ช่วยป้องกันการเข้าคิวในระดับนั้นและยังขจัดข้อกังวลใด ๆ ที่มีเนื้อหาของไฟล์หลาย ๆ อินเทอร์เลฟ (ซึ่งเป็นเรื่องที่เกี่ยวข้องน้อยลงในปัจจุบัน
ดิสก์ IOs จำนวนเท่าใดที่สามารถโดดเด่นไปยัง rowfile ในแต่ละครั้ง (จากมุมมองของ SQL Server ไม่จำเป็นต้องส่งไปยังระดับที่ต่ำกว่า) SQL Server มีข้อ จำกัด ไม่มาก (ที่ฉันเคยพบ) แต่สมมติว่าไฟล์อยู่ใน Windows PhysicalDisk เดียว (ผมไม่แนะนำให้ใช้ดิสก์แบบไดนามิกลายสำหรับ SQL Server ที่หัวข้อสำหรับเวลาอื่น) มีเป็นขีด จำกัด เป็น 255 ที่ฉันพูดถึงก่อนหน้านี้
ด้วยความมหัศจรรย์ของ SQL Server ที่อ่านแล้วและอะซิงโครนัส IO ฉันได้เห็นข้อความค้นหาที่เกิดขึ้นพร้อมกัน 4 ข้อความแต่ละคำสั่งที่ทำงานในไดรฟ์อนุกรมรวม "ความยาวคิวดิสก์ปัจจุบัน" มากกว่า 1200! เนื่องจากขีด จำกัด 255 จึงไม่สามารถทำได้กับเนื้อหา rowfile ทั้งหมดในฟิสิคัลดิสก์เดียว มันเทียบกับกลุ่มไฟล์หลักที่มี 8 ไฟล์โดยแต่ละไฟล์มีอยู่จริงในดิสก์
ดังนั้นการอ่านหัวอ่านอาจมีความก้าวร้าวมากและอาจทำให้เกิดปัญหาในการรอคิว IO พวกเขาสามารถก้าวร้าวมากจน rowfile อื่นอ่านและเขียนท้ายการรอ หากบันทึกธุรกรรมอยู่บน physicaldisk เดียวกับ rowfiles ในระหว่างการอ่าน readahead พร้อมกันและ txlog write มันง่ายมากที่จะรอให้เกิดขึ้น แม้ว่าการรอนั้นจะไม่อยู่ในระดับ "ความยาวคิวดิสก์ปัจจุบัน" อาจเป็นการรอคิวอุปกรณ์ (64 โดยค่าเริ่มต้นด้วย pvscsi)
การสำรองข้อมูลการอ่านเทียบกับ rowfiles นั้นสามารถทำได้โดยเฉพาะถ้า buffercount ถูกปรับเพื่อเพิ่มปริมาณการสำรองข้อมูลให้มากที่สุด
มีอีกหนึ่งชนิดของ SQL Server io ที่ต้องระวังเมื่อพิจารณาแยก txlogs: การรั่วไหลของแบบสอบถามเป็น tempdb เมื่อเกิดการรั่วไหลของแบบสอบถามการทำงานที่หกแต่ละรายการจะเขียนไปที่ tempdb มีคนงานคู่ขนานจำนวนมากทะลักในเวลาเดียวกันหรือไม่? ที่สามารถเขียนได้ค่อนข้าง การรักษา txlog ที่ไม่ว่างและ rowfiles ที่สำคัญอยู่ห่าง ๆ นั้นจะมีประโยชน์จริง ๆ :-)
ตอนนี้เป็นไปได้ที่จะเปลี่ยนความลึกของคิวอุปกรณ์เริ่มต้นสำหรับไดรเวอร์ pvscsi มันเริ่มต้นที่ 64 และสามารถตั้งค่าสูงถึง 254 ซึ่งเป็น storport ส่วนใหญ่จะผ่านไป แต่ระวังการเปลี่ยนแปลงสิ่งนี้ ฉันขอแนะนำให้จัดแนวความลึกของคิวอุปกรณ์เกสต์ให้ตรงกับความลึกของคิวโฮสต์ LUN ของ ESXi และการตั้งค่าความลึกของคิวโฮสต์ LUN ของ ESXi ต่อแนวทางปฏิบัติที่เหมาะสมของอาร์เรย์ ใช้ EMC VNX หรือไม่ ความลึกของคิวโฮสต์ LUN ควรเป็น 32 แขกใช้ RDM หรือไม่ ยิ่งใหญ่ ตั้งค่าความลึกของคิวอุปกรณ์ pvscsi ของผู้เยี่ยมชมเป็น 32 ดังนั้นจึงปรับให้สอดคล้องกับความลึกของคิวโฮสต์ LUN ESXi EMC VMAX โดยทั่วไปแล้ว 64 ที่ระดับโฮสต์ ESXi โดยมีแขก 64 คน Pure / Xtremio / IBM FlashSystem หรือไม่ บางครั้งความลึกของคิวโฮสต์ LUN จะถูกตั้งค่าสูงถึง 256! ไปข้างหน้าและตั้งค่าความลึกของคิวอุปกรณ์ pvscsi เป็น 254 (สูงสุดที่เป็นไปได้) จากนั้น
นี่คือลิงค์พร้อมคำแนะนำ
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
ลิงค์ยังพูดถึงการร้องขอหน้า - WhatAreThose ?? พวกเขากำหนดความลึกของคิวสำหรับอะแดปเตอร์ pvscsi แต่ละหน้ามี 32 ช่องในระดับความลึกของคิวอะแดปเตอร์ โดยค่าเริ่มต้น requestringpages คือ 8 สำหรับความลึกของคิวอะแด็ปเตอร์ที่ 256 ซึ่งสามารถตั้งค่าได้สูงถึง 32 สำหรับความลึกของคิวอะแด็ปเตอร์ 1024 สล็อต
สมมติว่าทุกอย่างเป็นค่าเริ่มต้น ฉันมีฟิสิคัลดิสก์ 8 รายการที่มี rowfiles อยู่และ SQL Server ไม่ว่าง มีค่าเฉลี่ย 32 "ความยาวคิวดิสก์ปัจจุบัน" ใน 8 และไม่มีใครสูงกว่า 64 (ทุกอย่างเหมาะกับคิวบริการอุปกรณ์ต่างๆ) ยอดเยี่ยม - ที่ให้ 256 OIO มันเหมาะกับคิวการบริการของอุปกรณ์มันเหมาะกับคิวการบริการของอะแดปเตอร์ดังนั้น 256 ทั้งหมดจึงทำให้แขกภายนอกเข้าคิวที่ระดับโฮสต์ ESX
แต่…หากสิ่งต่าง ๆ มีความยุ่งเหยิงเล็กน้อยดังนั้นค่าเฉลี่ย 64 กับคิวฟิสิคัลดิสก์บางตัวสูงถึง 128 สำหรับอุปกรณ์เหล่านั้นที่มียอดคงเหลือมากกว่า 64 รายการการใช้งานเกินจะอยู่ในคิวรอ หากมีมากกว่า 256 อยู่ในคิวบริการของอุปกรณ์ใน 8 ฟิสิคัลดิสก์ความเสียหายเกินขีดนั้นจะอยู่ในคิวรอจนกระทั่งสล็อตในคิวเซอร์วิสอะแด็ปเตอร์เปิดขึ้น
ในกรณีดังกล่าวให้เพิ่ม pvscsi vHBA อีกหนึ่งตัวและกระจายฟิสิคัลดิสก์ระหว่างสองเท่าของความลึกคิวอะแด็ปเตอร์รวมเป็น 512 คู่ io อื่น ๆ สามารถส่งผ่านจากเกสต์ไปยังโฮสต์ในเวลาเดียวกัน
สิ่งที่คล้ายกันสามารถทำได้โดยอยู่ที่อะแดปเตอร์ pvscsi หนึ่งตัวและเพิ่มหน้าการร้องขอ ไปที่ 16 จะให้ผล 512 สล็อตและ 32 ให้ผล 1024 สล็อต
เมื่อเป็นไปได้ฉันขอแนะนำให้ใช้ความกว้าง (เพิ่มอะแดปเตอร์) ก่อนจะลงลึก (เพิ่มความลึกของคิวอะแดปเตอร์) แต่…ในหลาย ๆ ระบบที่คึกคักที่สุดต้องทำทั้งสองอย่าง: ใส่ vHBAs 4 ตัวบนแขกและเพิ่มคำขอหน้า 32
มีข้อควรพิจารณาอื่น ๆ อีกมากมายเช่นกัน สิ่งต่าง ๆ เช่น sioc และการควบคุมปริมาณคิวที่ปรับตัวได้หากใช้ vmdks, การกำหนดค่ามัลติพา ธ , การกำหนดค่าอะแดปเตอร์ ESXi เกินความลึกคิว LUN ฯลฯ
แต่ฉันไม่ต้องการที่จะเกินเวลาการต้อนรับของฉัน :-)
Lonny Niederstadt @sqL_handLe