โดยทั่วไปแล้วการสำรองข้อมูลเต็มรูปแบบรายสัปดาห์ของเราจะเสร็จสิ้นในเวลาประมาณ 35 นาทีโดยมีการสำรองข้อมูลต่าง ๆ รายวันเสร็จใน ~ 5 นาที ตั้งแต่วันอังคารหนังสือพิมพ์รายวันใช้เวลาเกือบ 4 ชั่วโมงจึงจะเสร็จสมบูรณ์ บังเอิญสิ่งนี้เริ่มเกิดขึ้นทันทีหลังจากที่เราได้ SAN / disk config ใหม่
โปรดทราบว่าเซิร์ฟเวอร์กำลังทำงานในการผลิตและเราไม่มีปัญหาโดยรวมก็ทำงานได้อย่างราบรื่น - ยกเว้นปัญหา IO ที่ปรากฏตัวเป็นหลักในการสำรองข้อมูล
ดูที่ dm_exec_requests ระหว่างการสำรองข้อมูลการสำรองข้อมูลกำลังรอ ASYNC_IO_COMPLETION อยู่ตลอดเวลา อ๊ะเรามีข้อขัดแย้งของดิสก์!
อย่างไรก็ตามทั้ง MDF (บันทึกจะถูกเก็บไว้ในโลคัลดิสก์) หรือไดรฟ์สำรองไม่มีกิจกรรมใด ๆ (IOPS ~ = 0 - เรามีหน่วยความจำมากมาย) ความยาวคิวของดิสก์ ~ = 0 เช่นกัน CPU วนเวียนอยู่ประมาณ 2-3% ไม่มีปัญหาเช่นกัน
SAN เป็น Dell MD3220i LUN ที่ประกอบด้วยไดรฟ์ 6x10k SAS เซิร์ฟเวอร์นั้นเชื่อมต่อกับ SAN ผ่านทางฟิสิคัลสองพา ธ แต่ละอันจะผ่านสวิตช์ที่แยกต่างหากพร้อมการเชื่อมต่อที่ซ้ำซ้อนกับ SAN - ทั้งหมดสี่พา ธ ซึ่งทั้งสองนั้นแอ็คทีฟได้ตลอดเวลา ฉันสามารถตรวจสอบว่าการเชื่อมต่อทั้งสองใช้งานผ่านตัวจัดการงาน - แยกโหลดอย่างเท่าเทียมกัน การเชื่อมต่อทั้งสองแบบใช้งานเพล็กซ์เต็มรูปแบบ 1G
เราเคยใช้เฟรมจัมโบ้ แต่ฉันได้ปิดการใช้งานเพื่อแยกแยะปัญหาใด ๆ ที่นี่ - ไม่มีการเปลี่ยนแปลง เรามีเซิร์ฟเวอร์อื่น (OS + config เดียวกัน, 2008 R2) ที่เชื่อมต่อกับ LUN อื่นและไม่แสดงปัญหาใด ๆ อย่างไรก็ตามมันไม่ได้รัน SQL Server แต่เพียงแชร์ CIFS ที่ด้านบนของพวกเขา อย่างไรก็ตามหนึ่งในเส้นทางที่แนะนำของ LUN นั้นอยู่บนตัวควบคุม SAN เดียวกันกับ LUN ที่มีปัญหาดังนั้นฉันก็ตัดออกเช่นกัน
การรันการทดสอบ SQLIO สองสามไฟล์ (ไฟล์ทดสอบ 10G) ดูเหมือนว่า IO นั้นเหมาะสมแม้ว่าจะมีปัญหา:
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20
MBs/sec: 27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45 9 5 4 4 4 4 4 4 3 2 2 1 1 1 1 1 1 1 0 0 0 0 0 2
sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 4742.16
MBs/sec: 37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1
sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 1824.60
MBs/sec: 114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 1 3 14 4 14 43 4 2 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 6
sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 3238.88
MBs/sec: 202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 0 0 0 9 51 31 6 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0ฉันรู้ว่าสิ่งเหล่านี้ไม่ใช่การทดสอบแบบละเอียด แต่อย่างใด แต่พวกเขาทำให้ฉันรู้สึกสบายใจเมื่อรู้ว่ามันไม่ได้เป็นขยะสมบูรณ์ โปรดทราบว่าประสิทธิภาพการเขียนที่สูงขึ้นนั้นเกิดจากเส้นทาง MPIO ที่ใช้งานอยู่สองเส้นทางในขณะที่การอ่านจะใช้เส้นทางใดเส้นทางหนึ่งเท่านั้น
การตรวจสอบบันทึกเหตุการณ์ของแอปพลิเคชั่นจะเผยให้เห็นเหตุการณ์เช่นนี้ที่กระจัดกระจายไปทั่ว:
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150). The OS file handle is 0x0000000000003294. The offset of the latest long I/O is: 0x00000033da0000ไม่คงที่ แต่เกิดขึ้นเป็นประจำ (สองสามครั้งต่อชั่วโมงเพิ่มขึ้นระหว่างการสำรองข้อมูล) นอกเหนือจากเหตุการณ์นั้นแล้วบันทึกเหตุการณ์ของระบบจะโพสต์สิ่งเหล่านี้:
Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.สิ่งเหล่านี้เกิดขึ้นบนเซิร์ฟเวอร์ CIFS ที่ไม่เป็นปัญหาซึ่งทำงานบน SAN / Controller เดียวกันและจาก Googling ของฉันพวกเขาดูเหมือนจะไม่สำคัญ
โปรดทราบว่าเซิร์ฟเวอร์ทั้งหมดใช้ NICs เดียวกัน - Broadcom 5709Cs พร้อมไดรเวอร์ที่ทันสมัย เซิร์ฟเวอร์เองนั้นเป็นของ Dell R610
ฉันไม่แน่ใจว่าจะตรวจสอบอะไรต่อไป ข้อเสนอแนะใด ๆ
อัปเดต - ใช้งาน perfmon
ฉันพยายามบันทึกค่าเฉลี่ย ดิสก์วินาที / อ่านและเขียนตัวนับ perf ในขณะที่ทำการสำรองข้อมูล การสำรองข้อมูลเริ่มต้นอย่างเห็นได้ชัดจากนั้นโดยทั่วไปจะหยุดตายที่ 50% คลานช้าไปสู่ 100% แต่ใช้เวลา 20 เท่าในเวลาที่ควร
แสดงพา ธ SAN ทั้งสองที่ถูกใช้ประโยชน์จากนั้นดรอป
การสำรองข้อมูลเริ่มต้นรอบ 15:38:50 - สังเกตว่าทุกอย่างดูดีและมีจุดสูงสุดอยู่ด้วยกัน ฉันไม่ได้กังวลกับการเขียนเพียงแค่อ่านดูเหมือนจะแขวน
หมายเหตุการเปิด / ปิดการกระทำเล็ก ๆ น้อย ๆ แม้ว่าประสิทธิภาพที่โดดเด่นที่สุด
หมายเหตุสูงสุด 12 วินาทีถึงแม้ว่าโดยเฉลี่ยจะเป็นผลรวมที่ดี
อัปเดต - การสำรองอุปกรณ์ NUL
เพื่อแยกปัญหาการอ่านและทำให้สิ่งต่าง ๆ ง่ายขึ้นฉันจึงดำเนินการดังต่อไปนี้:
BACKUP DATABASE XXX TO DISK = 'NUL'ผลลัพธ์ที่ได้เหมือนกันทั้งหมด - เริ่มต้นด้วยการอ่านต่อเนื่องแล้วเริ่มต้นการดำเนินการต่อจากนั้น:
อัปเดต - IO แผงลอย
ฉันเรียกใช้แบบสอบถาม dm_io_virtual_file_stats จาก Jonathan Kehayias และหนังสือ Ted Kruegers (หน้า 29) ตามที่ Shawn แนะนำ ดูที่ไฟล์ 25 อันดับแรก (ไฟล์ข้อมูลหนึ่งไฟล์ - ผลลัพธ์ทั้งหมดเป็นไฟล์ข้อมูล) ดูเหมือนว่าการอ่านจะแย่กว่าการเขียน - อาจเป็นเพราะการเขียนไปที่แคช SAN โดยตรงในขณะที่คนอ่านเย็นต้องกดดิสก์ - คาดเดาว่า .
อัปเดต - รอสถิติ
ฉันทำการทดสอบสามครั้งเพื่อรวบรวมสถิติการรอ สถิติการรอคอยจะมีการสอบถามโดยใช้เกล็นแบล็กเบอร์ / พอล Randals สคริปต์ และเพื่อยืนยัน - การสำรองข้อมูลไม่ได้ถูกทำไว้กับเทป แต่ไปยัง iSCSI LUN ผลลัพธ์จะคล้ายกันถ้าทำกับโลคัลดิสก์โดยมีผลลัพธ์คล้ายกับการสำรองข้อมูล NUL
ล้างสถิติแล้ว วิ่งเป็นเวลา 10 นาทีโหลดปกติ:
ล้างสถิติแล้ว ใช้เวลา 10 นาทีโหลดปกติ + การสำรองข้อมูลปกติที่ทำงานอยู่ (ไม่เสร็จสมบูรณ์):
ล้างสถิติแล้ว ใช้เวลา 10 นาทีโหลดปกติ + กำลังสำรองข้อมูล NUL (ยังไม่เสร็จสิ้น):
อัปเดต - Wtf, Broadcom หรือไม่
จากคำแนะนำของ Mark Storey-Smiths และประสบการณ์ก่อนหน้านี้ของ Kyle Brandts กับ Broadcom NICs ฉันตัดสินใจทำการทดลอง เนื่องจากเรามีหลายเส้นทางที่ใช้งานอยู่ฉันสามารถเปลี่ยนการตั้งค่าของ NIC ได้ง่ายขึ้นทีละรายการโดยไม่ทำให้เกิดการขัดข้องใด ๆ
การปิดใช้งาน TOE และ Large Send Offload ทำให้การทำงานใกล้สมบูรณ์แบบ:
Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).แล้วผู้ร้ายคนไหน TOE หรือ LSO? เปิดใช้งาน TOE แล้ว LSO ปิดใช้งาน:
Didn't finish the backup as it took forever - just as the original problem!ปิดใช้งาน TOE, เปิดใช้งาน LSO - ดูดี:
Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).และเป็นตัวควบคุมฉันปิดใช้งานทั้ง TOE และ LSO เพื่อยืนยันว่าปัญหาหายไป:
Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).โดยสรุปดูเหมือนว่า Broadcom NICs TCP Offload Engine ที่เปิดใช้งานจะทำให้เกิดปัญหา ทันทีที่ TOE ปิดใช้งานทุกอย่างทำงานได้อย่างมีเสน่ห์ คาดเดาฉันจะไม่สั่ง Broadcom NIC อีกต่อไป
Update - Down ไปที่เซิร์ฟเวอร์ CIFS
วันนี้เซิร์ฟเวอร์ CIFSที่เหมือนกันและใช้งานได้เริ่มแสดงการร้องขอ IO ที่หยุดทำงาน เซิร์ฟเวอร์นี้ไม่ได้ใช้งาน SQL Server เพียงแค่ธรรมดา Windows Web Server 2008 R2 ที่ให้บริการแชร์ผ่าน CIFS ทันทีที่ฉันปิดใช้งาน TOE ด้วยเช่นกันทุกอย่างก็กลับมาทำงานได้อย่างราบรื่น
เพิ่งยืนยันว่าฉันจะไม่ใช้ TOE บน Broadcom NIC อีกเลยหากฉันไม่สามารถหลีกเลี่ยง Broadcom NIC ได้เลยนั่นคือ