สํารวจสถานการณ์ประสิทธิภาพการทํางาน

หากต้องการตัดสินใจว่าจะใช้เครื่องมือและความสามารถด้านประสิทธิภาพอย่างไร สิ่งสําคัญคือต้องดูประสิทธิภาพสําหรับ Azure SQL ผ่านสถานการณ์ต่าง ๆ

ทําความเข้าใจสถานการณ์ประสิทธิภาพการทํางานทั่วไป

เทคนิคทั่วไปสําหรับการแก้ไขปัญหาประสิทธิภาพการทํางาน SQL Server คือตรวจสอบว่าปัญหาด้านประสิทธิภาพการทํางาน เรียกใช้ (CPU สูง) หรือ รอ (รออยู่บนทรัพยากร) หรือไม่ แผนภาพต่อไปนี้แสดงแผนผังการตัดสินใจเพื่อตรวจสอบว่าปัญหาด้านประสิทธิภาพการทํางาน SQL Server กําลังทํางานหรือรออยู่หรือไม่ และวิธีการใช้เครื่องมือประสิทธิภาพในการกําหนดสาเหตุและโซลูชัน

ก่อนอื่น ดูการใช้ทรัพยากรโดยรวม สําหรับการปรับใช้ SQL Server มาตรฐาน คุณอาจใช้เครื่องมือ เช่น Performance Monitor ใน Windows หรือ top ใน Linux สําหรับ Azure SQL คุณสามารถใช้วิธีการต่อไปนี้:

• พอร์ทัล Azure/PowerShell/alerts

  Azure Monitor มีเมตริกแบบรวมเพื่อดูการใช้ทรัพยากรสําหรับ Azure SQL คุณยังสามารถตั้งค่าการแจ้งเตือนเพื่อค้นหาเงื่อนไขการใช้ทรัพยากรได้ด้วย

• sys.dm_db_resource_stats

  สําหรับฐานข้อมูล Azure SQL คุณสามารถดู DMV นี้เพื่อดูการใช้ทรัพยากร CPU หน่วยความจํา และ I/O สําหรับการปรับใช้ฐานข้อมูล DMV นี้ใช้สแนปช็อตของข้อมูลนี้ทุก ๆ 15 วินาที

• sys.server_resource_stats

  DMV นี้จะทํางานเหมือนกับ sys.dm_db_resource_statsแต่ใช้เพื่อดูการใช้ทรัพยากรสําหรับอินสแตนซ์ที่จัดการแล้วของ SQL สําหรับ CPU หน่วยความจํา และ I/O DMV นี้ยังใช้สแนปช็อตทุก 15 วินาที

• sys.dm_user_db_resource_governance

  สําหรับ Azure SQL Database DMV นี้จะส่งกลับการกําหนดค่าจริงและการตั้งค่าความจุที่ใช้โดยกลไกการกํากับดูแลทรัพยากรในฐานข้อมูลปัจจุบันหรือพูลแบบยืดหยุ่น

• sys.dm_instance_resource_governance

  สําหรับอินสแตนซ์ที่จัดการแล้วของ Azure SQL DMV นี้จะส่งกลับข้อมูลที่คล้ายกันเช่น sys.dm_user_db_resource_governanceแต่สําหรับอินสแตนซ์ที่จัดการแล้วของ SQL ปัจจุบัน

กำลัง เรียก ใช้

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

• การจัดเก็บคิวรี

  ใช้รายงานทรัพยากรที่ใช้มากที่สุดใน SSMS มุมมองแค็ตตาล็อกที่เก็บคิวรี หรือข้อมูลเชิงลึกด้านประสิทธิภาพการทํางานคิวรีในพอร์ทัล Azure (ฐานข้อมูล SQL Azure เท่านั้น) เพื่อค้นหาคิวรีที่ใช้ทรัพยากร CPU ส่วนใหญ่

• sys.dm_exec_requests

  ใช้ DMV นี้ใน Azure SQL เพื่อรับสแนปช็อตของสถานะของคิวรีที่ใช้งานอยู่ ค้นหาคิวรีที่มีสถานะของ RUNNABLE และชนิดการรอ SOS_SCHEDULER_YIELD เพื่อดูว่าคุณมีความจุ CPU เพียงพอหรือไม่

• sys.dm_exec_query_stats

  DMV นี้สามารถใช้ได้เช่นเดียวกับ Query Store เพื่อค้นหาคิวรีที่ใช้ทรัพยากรสูงสุด ซึ่งจะพร้อมใช้งานสําหรับแผนคิวรีที่แคชเท่านั้น ในขณะที่ Query Store มีบันทึกประสิทธิภาพในอดีตแบบถาวร DMV นี้ยังช่วยให้คุณสามารถค้นหาแผนคิวรีสําหรับคิวรีที่แคชไว้ได้

• sys.dm_exec_procedure_stats

  DMV นี้มีข้อมูลเหมือนกับ sys.dm_exec_query_statsยกเว้นข้อมูลประสิทธิภาพการทํางานสามารถดูได้ที่ระดับกระบวนงานที่เก็บไว้

  หลังจากที่คุณกําหนดว่าคิวรีใดที่ใช้ทรัพยากรมากที่สุด คุณอาจต้องตรวจสอบว่าคุณมีทรัพยากร CPU เพียงพอสําหรับปริมาณงานของคุณหรือไม่ คุณอาจดีบักแผนคิวรีด้วยเครื่องมือ เช่น การทําโปรไฟล์คิวรีแบบน้ําหนักเบา คําสั่ง SET, Query Store หรือการติดตามเหตุการณ์แบบขยายเวลา

กำลังรอ

ถ้าปัญหาของคุณดูเหมือนจะไม่เป็นการใช้ทรัพยากร CPU สูง อาจเป็นได้ว่าปัญหาด้านประสิทธิภาพการทํางานเกี่ยวข้องกับการรอทรัพยากร สถานการณ์ที่เกี่ยวข้องกับการรอบนทรัพยากรได้แก่:

• การรอ I/O
• การรอล็อก
• การรอสลัก
• ขีดจํากัดของพูลบัฟเฟอร์
• เงินช่วยเหลือหน่วยความจํา
• การลดข้อมูลแคชของแผน

เพื่อทําการวิเคราะห์สถานการณ์ที่รอโดยทั่วไป คุณจะดูที่เครื่องมือต่อไปนี้:

• sys.dm_os_wait_stats

  ใช้ DMV นี้เพื่อดูชนิดการรอสูงสุดสําหรับฐานข้อมูลหรืออินสแตนซ์ ซึ่งจะแนะนําคุณเกี่ยวกับการดําเนินการต่อไป โดยขึ้นอยู่กับชนิดการรอสูงสุด

• sys.dm_exec_requests

  ใช้ DMV นี้เพื่อค้นหาชนิดการรอเฉพาะสําหรับคิวรีที่ใช้งานอยู่เพื่อดูว่าทรัพยากรใดที่กําลังรออยู่ ซึ่งอาจเป็นสถานการณ์การบล็อกมาตรฐาน โดยกําลังรอการล็อกจากผู้ใช้อื่น

• sys.dm_os_waiting_tasks

  คุณสามารถใช้ DMV นี้เพื่อค้นหาชนิดการรอสําหรับงานเฉพาะสําหรับคิวรีเฉพาะที่กําลังดําเนินการอยู่ ในขณะนี้ อาจเห็นว่าเหตุใดจึงใช้เวลานานกว่าปกติ sys.dm_os_waiting_tasks ประกอบด้วยสถิติการรอแบบสดที่ sys.dm_os_wait_stats ผลรวมเมื่อเวลาผ่านไป

• การจัดเก็บคิวรี

  Query Store มีรายงานและมุมมองแค็ตตาล็อกที่แสดงการรวมของการรอสูงสุดสําหรับการดําเนินการแผนคิวรี สิ่งสําคัญคือต้องทราบว่าการรอ CPU นั้นเทียบเท่ากับปัญหา ที่กําลังทํางานอยู่

สถานการณ์เฉพาะสําหรับ Azure SQL

มีสถานการณ์ด้านประสิทธิภาพการทํางานบางอย่าง ทั้งการเรียกใช้และการรอ ที่เฉพาะเจาะจงกับ Azure SQL ซึ่งรวมถึงการกํากับดูแลบันทึก ขีดจํากัดผู้ปฏิบัติงาน การรอที่พบสําหรับระดับบริการที่สําคัญทางธุรกิจ และรอการปรับใช้เฉพาะสําหรับ Hyperscale

การกํากับดูแลรายการบันทึก

Azure SQL สามารถใช้การกํากับดูแลอัตราบันทึกเพื่อบังคับใช้ขีดจํากัดทรัพยากรในการใช้งานบันทึกธุรกรรม คุณอาจต้องการการบังคับใช้นี้เพื่อให้แน่ใจว่าขีดจํากัดทรัพยากรและเพื่อให้เป็นไปตาม SLA ที่สัญญาไว้ การกํากับดูแลรายการบันทึกอาจเห็นได้จากชนิดการรอต่อไปนี้:

• LOG_RATE_GOVERNOR: รอฐานข้อมูล Azure SQL
• POOL_LOG_RATE_GOVERNOR: รอ Elastic Pools
• INSTANCE_LOG_GOVERNOR: รออินสแตนซ์ที่จัดการแล้วของ Azure SQL
• HADR_THROTTLE_LOG_RATE*: รอเวลาแฝงทางธุรกิจที่สําคัญและทางภูมิศาสตร์การจําลองแบบ

ขีดจํากัดของผู้ปฏิบัติงาน

SQL Server ใช้พูลผู้ปฏิบัติงานของเธรด แต่มีขีดจํากัดจํานวนสูงสุดของผู้ปฏิบัติงาน แอปพลิเคชันที่มีผู้ใช้พร้อมกันจํานวนมากอาจเข้าถึงขีดจํากัดของผู้ปฏิบัติงานที่บังคับใช้สําหรับฐานข้อมูล Azure SQL และอินสแตนซ์ที่จัดการแล้วของ SQL:

• Azure SQL Database จํากัดตามระดับบริการและขนาด ถ้าคุณเกินขีดจํากัดนี้ คิวรีใหม่จะแสดงข้อผิดพลาด
• ในขณะนี้ อินสแตนซ์ที่จัดการแล้วของ SQL ใช้ max worker threadsดังนั้นผู้ปฏิบัติงานที่เกินขีดจํากัดนี้อาจเห็นการรอ THREADPOOL

การรอ HADR ที่สําคัญทางธุรกิจ

หากคุณใช้ระดับบริการที่สําคัญทางธุรกิจ คุณอาจเห็นประเภทการรอต่อไปนี้โดยไม่คาดคิด:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

แม้ว่าการรอเหล่านี้อาจไม่ทําให้แอปพลิเคชันของคุณช้าลง แต่คุณอาจไม่คาดหวังที่จะเห็นสิ่งเหล่านี้ โดยปกติจะใช้เฉพาะกับการใช้กลุ่มความพร้อมใช้งาน On เสมอ ระดับธุรกิจที่สําคัญใช้เทคโนโลยีกลุ่มความพร้อมใช้งานเพื่อใช้ SLA และความพร้อมใช้งานคุณลักษณะของระดับบริการที่สําคัญทางธุรกิจ ดังนั้นประเภทการรอเหล่านี้จึงคาดหมาย เวลารอที่นานอาจระบุถึงคอขวด เช่น เวลาแฝง I/O หรือแบบจําลองที่อยู่เบื้องหลัง

Hyperscale

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

ในแบบฝึกหัดถัดไป คุณจะได้เรียนรู้วิธีการตรวจสอบและแก้ไขปัญหาประสิทธิภาพการทํางานสําหรับ Azure SQL โดยใช้เครื่องมือและความรู้ที่คุณได้รับในหน่วยนี้