ความถี่ของการแฮช / การเรียงลำดับที่หกลงใน tempdb เกี่ยวข้องกับอะไร

แอปพลิเคชั่นองค์กรของเราใช้ SQL Server สำหรับจัดเก็บข้อมูลและเป็นระบบ OLTP เป็นหลัก อย่างไรก็ตามส่วนประกอบที่สำคัญของแอปพลิเคชันของเราสร้างภาระงาน OLAP ที่มีนัยสำคัญ

เวลาในการเขียนของเราไปที่ tempdb ประมาณ 100ms แนวโน้มนี้ถือเป็นช่วงเวลาและALLOW_SNAPSHOT_ISOLATIONมีการเปิดปิด เรากำลังแก้ไขปัญหานี้เกี่ยวกับปัญหาและสิ่งที่น่าสนใจเพียงอย่างเดียวที่เราพบคือมีแฮชและการเรียงลำดับการรั่วไหลจำนวนมากไปยัง tempdb เราคาดการณ์ว่าสิ่งนี้มาจากภาระงาน OLAP ของเรา

คำถาม

ความถี่ของการรั่วไหลเกี่ยวข้องกับอะไร? ใด? กี่ครั้ง / วินาที? ข้อมูลเบื้องต้นของเราระบุว่าเรามีแฮชการรั่วไหลประมาณ 2 ครั้งต่อวินาทีและ 25 การเรียงลำดับหกครั้งต่อนาที

เป็นไปได้หรือไม่ที่ความถี่ของการรั่วไหลนี้อาจเป็นผู้ร้ายหลักในเวลาแฝงการเขียนระดับสูงของเรา

ข้อมูลอื่น ๆ

เรากำลังใช้หลายไฟล์สำหรับ tempdb ตามที่แนะนำต่อจำนวนคอร์ ไฟล์ tempdb อยู่ใน RAID 1 + 0 SAN (ที่มี SSD ประสิทธิภาพสูง) แต่เป็นอุปกรณ์เดียวกับข้อมูล DB หลักและไฟล์บันทึก ไฟล์ tempdb มีขนาดใหญ่พอที่จะเติบโตไม่บ่อยนัก เราไม่ได้ใช้การตั้งค่าสถานะการสืบค้นกลับ 1117 หรือ 1118 ตัวแปรอื่นคือการตั้งค่านี้มีการใช้งานร่วมกันสำหรับฐานข้อมูลที่แตกต่างกันจำนวนมากที่ทุกคนมีประสบการณ์ในการโหลดสูง

เวลาในการตอบสนองการเขียน 100 ms ของเรานั้นสูงกว่าช่วงที่ยอมรับได้สำหรับ tempdb การเขียนเวลาในการตอบสนองที่เราพบใน MSDN, SQL Skills และไซต์อื่น ๆ อย่างไรก็ตามการเขียนเวลาแฝงสำหรับฐานข้อมูลอื่น ๆ ของเรานั้นดี (ต่ำกว่า 10ms) จากสถิติอื่น ๆ ดูเหมือนว่าเรากำลังใช้ tempdb อย่างมากโดยเฉพาะกับวัตถุภายใน ดังนั้นเราจึงพยายามหาสาเหตุที่แอปพลิเคชันของเราใช้วัตถุภายในอย่างหนัก

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

เป็นไปได้หรือไม่ที่ความถี่ของการรั่วไหลนี้อาจเป็นผู้ร้ายหลักในเวลาแฝงการเขียนระดับสูงของเรา

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

SQL Server มีตัวชี้วัดและข้อมูล DMV ที่หลากหลายเพื่อช่วยคุณแก้ไขปัญหาต่าง ๆ ที่มีผลต่อความดัน tempdb ซึ่งส่วนใหญ่จะกล่าวถึงในบทความทางเทคนิคของ Microsoft "การทำงานกับ tempdb ใน SQL Server 2005" (ใช้กับทุกรุ่น 2005 เป็นต้นไป) )

คุณควรจะสามารถใช้คำแนะนำและแบบสอบถามการวินิจฉัยที่มีอยู่ในเอกสารนั้นเพื่อเริ่มต้นระบุสาเหตุหลักของแรงกดดัน tempdb ใด ๆ อย่าเพิกเฉยเช่นกิจกรรมในเวอร์ชั่นร้านเพราะALLOW_SNAPSHOT_ISOLATIONไม่ได้เปิดใช้งาน คุณลักษณะหลายอย่างใช้ที่เก็บรุ่น (เช่นทริกเกอร์, MARS, RCSI) นอกเหนือจากการแยกสแนปชอต

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

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