ปัญหาประสิทธิภาพการทำงานที่สำคัญใน SQL Server ที่ผลิตของเราฉันจะแก้ไขปัญหานี้ได้อย่างไร

คำถามนี้เป็นคำถามที่ตามมาสำหรับคำถามนี้:
ปัญหาประสิทธิภาพการทำงานที่แปลกกับ SQL Server 2016

ตอนนี้เรามีประสิทธิภาพด้วยระบบนี้ แม้ว่าฐานข้อมูลแอปพลิเคชันอื่นจะถูกเพิ่มไปยัง SQL Server นี้ตั้งแต่โพสต์ล่าสุดของฉัน

นี่คือสถิติของระบบ:

• 128 GB RAM (หน่วยความจำสูงสุด 110GB สำหรับ SQL Server)
• 4 คอร์ที่ 2.6 GHz
• การเชื่อมต่อเครือข่าย 10 GBit
• ที่เก็บข้อมูลทั้งหมดใช้ SSD
• ไฟล์โปรแกรมไฟล์บันทึกไฟล์ฐานข้อมูลและ tempdb อยู่บนพาร์ติชันแยกต่างหากของเซิร์ฟเวอร์
• Windows Server 2012 R2
• VMware เวอร์ชัน HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• เครื่องมือ VMware รุ่น 10.0.9 สร้าง 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 ตุลาคม 2559 18:17:30 ลิขสิทธิ์ (c) Microsoft Corporation Standard Edition (64 บิต) บน Windows Server 2012 R2 มาตรฐาน 6.3 (รุ่น 9600:) (Hypervisor)

ระบบของเรามีปัญหาด้านประสิทธิภาพที่สำคัญ การใช้ CPU และเธรดที่สูงมาก:

รอสถิติของการตรวจสอบกิจกรรม (ฉันรู้ว่ามันไม่น่าเชื่อถือมาก)

ผลลัพธ์ของ sp_blitzfirst:

ผลลัพธ์ของ sp_configure:

การตั้งค่าเซิร์ฟเวอร์ขั้นสูง (โชคร้ายเป็นภาษาเยอรมันเท่านั้น)

ฉันเปลี่ยนการตั้งค่า MAXDOP

ฉันรู้ว่านี้ propably ไม่เป็นปัญหากับ SQL Server ตัวเอง เป็นไปได้อย่างมากปัญหาเกี่ยวกับ virtualization (vmware), เครือข่ายที่เกี่ยวข้อง (ฉันทดสอบแล้ว) หรือแอปพลิเคชันเอง ฉันแค่ต้องการตอกตะปูลง

ASYNC_NETWORK_IO สูงจะส่งผลให้มีการนับจำนวนเธรดสูงสำหรับกระบวนการ sqlserver หรือไม่ ฉันคิดว่ามัน spwan คนงานจำนวนมากเพราะไม่สามารถปิดกระทู้ นั่นถูกต้องใช่ไหม?

ฉันจะให้ข้อมูลเพิ่มเติมที่คุณต้องการ ขอบคุณล่วงหน้าสำหรับการสนับสนุนของคุณ!

แก้ไข:

ผลลัพธ์ของ sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

ลำดับความสำคัญ 1: สำรองข้อมูล :

• การสำรองข้อมูลไปยังไดรฟ์เดียวกันที่มีฐานข้อมูลอยู่ - มีการสำรองข้อมูล 5 ครั้งในไดรฟ์ E: \ ในสองสัปดาห์ที่ผ่านมา สิ่งนี้แสดงถึงความเสี่ยงที่ร้ายแรงหากอาร์เรย์นั้นล้มเหลว

ลำดับความสำคัญ 1: ความน่าเชื่อถือ :

• DBCC CHECKDB สุดท้ายที่ดีกว่า 2 สัปดาห์

  • babtec_prod - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: 2017-08-20 00: 01: 01.513

  • D3PR - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: ไม่เคย

  • DEMO77 - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: 2016-02-23 20: 31: 38.590

  • FINP - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: 2017-05-18 22: 10: 48.120

  • master - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: ไม่เคย

  • แบบ

  • msdb

  • PROD77 - CHECKDB ที่ประสบความสำเร็จครั้งล่าสุด: 2016-02-23 21: 33: 24.343

ลำดับความสำคัญที่ 10: ประสิทธิภาพการทำงาน :

• Query Store Disabled - คุณลักษณะ SQL Query Store 2016 ใหม่ไม่ได้เปิดใช้งานบนฐานข้อมูลนี้

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

ลำดับความสำคัญที่ 50: เหตุการณ์ DBCC :

• DBCC DROPCLEANBUFFERS - ผู้ใช้ schorsch เรียกใช้ DBCC DROPCLEANBUFFERS 1 ครั้งระหว่าง 21 ก.ย. 2017 11:57 น. และ 21 ก.ย. 2017 11:57 น. หากนี่คือกล่องผลิตโปรดทราบว่าคุณกำลังล้างข้อมูลทั้งหมดออกจากหน่วยความจำเมื่อเกิดเหตุการณ์นี้ขึ้น สัตว์ประหลาดชนิดไหนที่จะทำเช่นนั้น?

• DBCC SHRINK% - ผู้ใช้ schorsch เรียกใช้ไฟล์ย่อขนาด 6 ครั้งระหว่าง 21 Sep 2017 11:51 PM และ Okt 4 2017 9:02 AM ดังนั้นพวกเขากำลังพยายามแก้ไขการทุจริตหรือทำให้เกิดความเสียหายหรือไม่

• กิจกรรมโดยรวม - มีการจัดกิจกรรม DBCC จำนวน 287 รายการระหว่างวันที่ 19 ก.ย. 2560 เวลา 13:40 น. และ ต.ค. 4 2017 2017 น. สิ่งนี้ไม่รวม CHECKDB และเหตุการณ์อื่น ๆ ที่มักจะเป็นอันตรายต่อ DBCC

ลำดับความสำคัญที่ 50: ประสิทธิภาพการทำงาน :

• การเจริญเติบโตของไฟล์ช้า PROD77 - การเติบโต 2 ครั้งใช้เวลามากกว่า 15 วินาทีในแต่ละครั้ง พิจารณาการตั้งค่าไฟล์อัตโนมัติให้เพิ่มทีละน้อย

ลำดับความสำคัญ 50: ความน่าเชื่อถือ :

• การยืนยันหน้าไม่ดีที่สุด babtec_prod - ฐานข้อมูล [babtec_prod] มี TORN_PAGE_DETECTION สำหรับการตรวจสอบหน้า SQL Server อาจมีปัญหาในการจดจำและกู้คืนจากความเสียหายของที่เก็บข้อมูล พิจารณาใช้ CHECKSUM แทน

ลำดับความสำคัญ 100: ประสิทธิภาพการทำงาน :

• มีแผนการมากมายสำหรับ One Query - 3576 แผนสำหรับคิวรีเดียวในแคชแผน - ซึ่งหมายความว่าเราอาจมีปัญหาเกี่ยวกับการกำหนดพารามิเตอร์

ลำดับความสำคัญ 110: ประสิทธิภาพ :

• ตารางที่ใช้งานอยู่โดยไม่มีดัชนีเป็นกลุ่ม

  • babtec_prod - ฐานข้อมูล [babtec_prod] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

  • D3PR - ฐานข้อมูล [D3PR] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

  • DEMO77 - ฐานข้อมูล [DEMO77] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

  • FINP - ฐานข้อมูล [FINP] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

  • GridVis_EnMs - ฐานข้อมูล [GridVis_EnMs] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

  • PROD77 - ฐานข้อมูล [PROD77] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งถูกสอบถามอย่างแข็งขัน

ลำดับความสำคัญ 150: ประสิทธิภาพ :

• กุญแจต่างประเทศไม่น่าเชื่อถือ

  • babtec_prod - ฐานข้อมูล [babtec_prod] มีคีย์ต่างประเทศที่อาจถูกปิดใช้งานข้อมูลมีการเปลี่ยนแปลงแล้วเปิดใช้งานคีย์อีกครั้ง การเปิดใช้งานคีย์ไม่เพียงพอสำหรับเครื่องมือเพิ่มประสิทธิภาพในการใช้คีย์นี้ - เราต้องแก้ไขตารางโดยใช้พารามิเตอร์ WITH CHECK CHECK CONSTRAINT

  • D3PR - ฐานข้อมูล [D3PR] มีคีย์ต่างประเทศที่อาจปิดใช้งานข้อมูลมีการเปลี่ยนแปลงและเปิดใช้งานคีย์อีกครั้ง การเปิดใช้งานคีย์ไม่เพียงพอสำหรับเครื่องมือเพิ่มประสิทธิภาพในการใช้คีย์นี้ - เราต้องแก้ไขตารางโดยใช้พารามิเตอร์ WITH CHECK CHECK CONSTRAINT

• ตารางที่ไม่แอ็คทีฟโดยไม่มีดัชนีแบบคลัสเตอร์

  • D3PR - ฐานข้อมูล [D3PR] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ที่ยังไม่ถูกสอบถามตั้งแต่เริ่มรีสตาร์ทครั้งล่าสุด สิ่งเหล่านี้อาจเป็นตารางสำรองข้อมูลที่ถูกทิ้งไว้อย่างไม่ระมัดระวัง

  • GridVis_EnMs - ฐานข้อมูล [GridVis_EnMs] มีฮีป - ตารางที่ไม่มีดัชนีคลัสเตอร์ - ซึ่งยังไม่ถูกสอบถามตั้งแต่เริ่มการทำงานครั้งล่าสุด สิ่งเหล่านี้อาจเป็นตารางสำรองข้อมูลที่ถูกทิ้งไว้อย่างไม่ระมัดระวัง

• Triggers on Tables babtec_prod - ฐานข้อมูล [babtec_prod] มี 26 ทริกเกอร์

ลำดับความสำคัญ 170: การกำหนดค่าไฟล์ :

• ฐานข้อมูลระบบบนไดรฟ์ C

  • master - ฐานข้อมูลหลักมีไฟล์ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

  • model - ฐานข้อมูล model มีไฟล์อยู่ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

  • msdb - ฐานข้อมูล msdb มีไฟล์อยู่ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

ลำดับความสำคัญ 170: ความน่าเชื่อถือ :

• ตั้งค่าขนาดไฟล์สูงสุด

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_data_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_data_idx_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_firm_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_firm_idx_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_log_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_phys_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_phys_idx_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 61440MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_sys_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 20480MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_usr_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 20480MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_wort_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 20480MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

  • D3PR - ไฟล์ฐานข้อมูล [D3PR] d3_wort_idx_01 มีขนาดไฟล์สูงสุดที่ตั้งไว้ที่ 20480MB หากเนื้อที่ว่างเหลืออยู่ฐานข้อมูลจะหยุดทำงานแม้ว่าอาจจะมีพื้นที่ว่างบนไดรฟ์

ลำดับความสำคัญ 200: ข้อมูล :

• การบีบอัดข้อมูลสำรองเริ่มต้นปิด - การสำรองข้อมูลเต็มรูปแบบที่ไม่มีการบีบอัดเกิดขึ้นเมื่อเร็ว ๆ นี้และการบีบอัดข้อมูลสำรองไม่ได้เปิดในระดับเซิร์ฟเวอร์ การบีบอัดข้อมูลสำรองรวมอยู่ใน SQL Server 2008R2 และใหม่กว่าแม้ใน Standard Edition เราขอแนะนำให้เปิดการบีบอัดข้อมูลสำรองตามค่าเริ่มต้นเพื่อให้การสำรองข้อมูลแบบเฉพาะกิจจะได้รับการบีบอัด

• การจัดเรียงคือ Latin1_General_CS_AS FINP - ความแตกต่างในการเปรียบเทียบระหว่างฐานข้อมูลผู้ใช้กับ tempdb อาจทำให้เกิดข้อขัดแย้งโดยเฉพาะเมื่อเปรียบเทียบค่าสตริง

• การเรียงหน้าคือ SQL_Latin1_General_CP1_CI_AS - ความแตกต่างในการเปรียบเทียบระหว่างฐานข้อมูลผู้ใช้กับ tempdb อาจทำให้เกิดข้อขัดแย้งโดยเฉพาะเมื่อเปรียบเทียบค่าสตริง

  • DEMO77

  • PROD77

• เซิร์ฟเวอร์ที่เชื่อมโยงได้รับการกำหนดค่า - BWIN2 \ INFOR ได้รับการกำหนดค่าเป็นเซิร์ฟเวอร์ที่เชื่อมโยง ตรวจสอบการกำหนดค่าความปลอดภัยในขณะที่มันกำลังเชื่อมต่อกับ sa เพราะผู้ใช้ที่สอบถามมันจะได้รับสิทธิ์ระดับผู้ดูแลระบบ

ลำดับความสำคัญ 200: การตรวจสอบ :

• งานของตัวแทนโดยไม่มีอีเมลล้มเหลว

  • ยังไม่ได้ตั้งค่างาน syspolicy_purge_history เพื่อแจ้งให้โอเปอเรเตอร์ทราบหากล้มเหลว

  • งาน upd_durchpreis_monatl ไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่ามันล้มเหลว

  • งาน upd_fertmengen_woche ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบหากมันล้มเหลว

  • งาน upd_liegezeit_monatl ไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่ามันล้มเหลว

  • งาน upd_vertreter_diff ยังไม่ได้รับการตั้งค่าเพื่อแจ้งเตือนผู้ปฏิบัติงานหากล้มเหลว

  • งาน UPDATE_CONNECT_IK ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ประกอบการทราบหากมันล้มเหลว

  • งาน Wartung.Cleanup ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ประกอบการทราบหากล้มเหลว

  • งาน Wartung.DBCC Check DB ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่ามันล้มเหลว

  • งาน Wartung.Index neu erstellen ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ประกอบการทราบหากเกิดความผิดพลาด

  • งาน Wartung.Statistiken aktualisieren ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ประกอบการทราบหากมันล้มเหลว

  • งาน Wartung.Transactionlog Backup ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่าล้มเหลว

  • งาน Wartung.Vollbackup SystemDB ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่าล้มเหลว

  • งาน Wartung.Vollbackup UserDB ยังไม่ได้รับการตั้งค่าเพื่อแจ้งให้ผู้ปฏิบัติงานทราบว่ามันล้มเหลว

• ไม่มีการแจ้งเตือนสำหรับความเสียหาย - ไม่มีการแจ้งเตือน บริษัท ตัวแทนของเซิร์ฟเวอร์ SQL สำหรับข้อผิดพลาด 823, 824 และ 825 ข้อผิดพลาดทั้งสามนี้สามารถแจ้งเตือนคุณเกี่ยวกับความล้มเหลวของฮาร์ดแวร์ก่อน การเปิดใช้งานอาจทำให้คุณปวดใจได้มาก

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

• ไม่ได้ตั้งค่าการแจ้งเตือนทั้งหมด - มีการกำหนดค่าการแจ้งเตือนตัวแทนเซิร์ฟเวอร์ SQL ทั้งหมด นี่เป็นวิธีที่ง่ายและฟรีในการรับการแจ้งเตือนเรื่องการทุจริตงานล้มเหลวหรือการหยุดทำงานครั้งใหญ่แม้กระทั่งก่อนที่ระบบการตรวจสอบจะมารับ

ลำดับความสำคัญ 200: การกำหนดค่าเซิร์ฟเวอร์ที่ไม่ใช่ค่าเริ่มต้น :

• Agent XP - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• Database Mail XPs - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• ภาษาของข้อความเริ่มต้นเต็มรูปแบบ - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 1033 และได้รับการตั้งค่าเป็น 1031

• ภาษาเริ่มต้น - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• ระดับการเข้าถึง filestream - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• ระดับสูงสุดของการขนาน - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 4

• หน่วยความจำเซิร์ฟเวอร์สูงสุด (MB) - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 2147483647 และได้รับการตั้งค่าเป็น 115000

• หน่วยความจำเซิร์ฟเวอร์ขั้นต่ำ (MB) - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และตั้งไว้ที่ 10,000

• การเชื่อมต่อผู้ดูแลระบบระยะไกล - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

ลำดับความสำคัญ 200: ประสิทธิภาพ :

• เกณฑ์ต้นทุนสำหรับการขนาน - ตั้งค่าเป็น 5 ซึ่งเป็นค่าเริ่มต้น การเปลี่ยนการตั้งค่า sp_configure นี้อาจลดการรอของ CXPACKET

• Snapshot Backups เกิดขึ้น - การแบ็คอัพข้อมูล 9 สแนปชอตเกิดขึ้นในสองสัปดาห์ที่ผ่านมาซึ่งบ่งบอกว่า IO อาจหยุดค้าง

ลำดับความสำคัญ 210: การกำหนดค่าฐานข้อมูลที่ไม่ใช่ค่าเริ่มต้น :

• Read Committed Snapshot Isolation Enabled - การตั้งค่าฐานข้อมูลนี้ไม่ใช่ค่าเริ่มต้น

  • D3PR

  • FINP

• Recursive Triggers Enabled - การตั้งค่าฐานข้อมูลนี้ไม่ใช่ค่าเริ่มต้น

  • DEMO77

  • PROD77

• Snapshot Isolation Enabled FINP - การตั้งค่าฐานข้อมูลนี้ไม่ใช่ค่าเริ่มต้น

ลำดับความสำคัญ 240: รอสถิติ :

• 1 - ASYNC_NETWORK_IO - รอคอย 225.9 ชั่วโมง, รอเวลาเฉลี่ย 143.5 นาทีต่อชั่วโมง, รอสัญญาณ 0.2%, รองาน 2146022 คน, รองานเฉลี่ย 378.9 ms

• 2 - CXPACKET - การรอ 43.1 ชั่วโมง, 27.4 นาทีโดยเฉลี่ยต่อชั่วโมงต่อชั่วโมง, การรอสัญญาณ 1.5%, 32608391 งานที่รอ, 4.8 ms เวลารอเฉลี่ย

ลำดับความสำคัญ 250: ข้อมูล :

• SQL Server ทำงานภายใต้บัญชีบริการ NT

  • ฉันทำงานเป็น NT Service \ MSSQL $ INFOR ฉันหวังว่าฉันมีบัญชีบริการ Active Directory แทน

  • ฉันทำงานเป็น NT Service \ SQLAgent $ INFOR ฉันหวังว่าฉันมีบัญชีบริการ Active Directory แทน

ลำดับความสำคัญ 250: ข้อมูลเซิร์ฟเวอร์ :

• Default Trace Contents - การติดตามเริ่มต้นเก็บข้อมูล 760 ชั่วโมงระหว่าง 3 ก.ย. 2017 8:34 PM และ Okt 5 2017 12:50 PM ไฟล์การติดตามเริ่มต้นอยู่ใน: Server \ MSSQL13.INFOR \ MSSQL \ Log SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Drive C Space - 21308.00MB ฟรีใน C drive

• Drive D Space - 280008.00MB ฟรีใน D drive
• Drive E Space - 281618.00MB ฟรีบนไดรฟ์ E

• Drive F Space - 60193.00MB ฟรีบนไดรฟ์ F

• ฮาร์ดแวร์ - ตัวประมวลผลเชิงตรรกะ: 4. หน่วยความจำกายภาพ: 128GB

• ฮาร์ดแวร์ - การกำหนดค่า NUMA - โหนด: 0 สถานะ: ออนไลน์ตัวกำหนดเวลาออนไลน์: 4 ตัวกำหนดเวลาออฟไลน์: 0 กลุ่มตัวประมวลผล: 0 หน่วยความจำโหนด: 0 หน่วยความจำ VAS สงวนไว้ GB: 281

• เซิร์ฟเวอร์รีสตาร์ทครั้งล่าสุด - Okt 1 2017 2:21 PM

• ชื่อเซิร์ฟเวอร์ - BWINPDB \ INFOR

• บริการ

  • บริการ: SQL Server (INFOR) ทำงานภายใต้บัญชีบริการ NT Service \ MSSQL $ INFOR เวลาเริ่มต้นล่าสุด: Okt 1 2017 2:22 PM ประเภทเริ่มต้น: อัตโนมัติกำลังทำงานอยู่

  • บริการ: SQL Server-Agent (INFOR) ทำงานภายใต้บัญชีบริการ NT Service \ SQLAgent $ INFOR เวลาเริ่มต้นล่าสุด: ไม่แสดง .. ประเภทการเริ่มต้น: อัตโนมัติกำลังทำงานอยู่

• SQL Server รีสตาร์ทครั้งล่าสุด - Okt 1 2017 2:22 PM

• บริการเซิร์ฟเวอร์ SQL - รุ่น: 13.0.4001.0 ระดับแพตช์: SP1 รุ่น: Standard Edition (64 บิต) AlwaysOn Enabled: 0. AlwaysOn Mgr สถานะ: 2

• เซิร์ฟเวอร์เสมือน - ประเภท: (HYPERVISOR)

• Windows Version - คุณกำลังใช้งาน Windows รุ่นที่ทันสมัย: Server 2012R2 era, 6.3

ลำดับความสำคัญ 254: Rundate :

• บันทึกของกัปตัน: ทำบางสิ่งบางอย่างและบางสิ่งบางอย่าง ...

แก้ไข:

ฉันได้ศึกษาแล้วว่าแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการตั้งค่าเซิร์ฟเวอร์ sql ด้วย vmware และเราได้ตั้งค่าส่วนใหญ่ตามเอกสารนี้ แม้ว่าไฮเปอร์เธรดจะไม่เปิดใช้งานและ NUMA ไม่ได้ใช้งานบนโฮสต์ vmware SQL Server ถูกตั้งค่าเป็น NUMA แม้ว่า

แก้ไข:

ฉันได้ออก RECONFIGURE หลังจากตั้งค่า thresold สำหรับ parallelism เป็น 50 แล้วการตั้งค่า MAXDOP ของฉันยังไม่ได้กำหนดค่า

ฉันยังตรวจสอบกับผู้ดูแลระบบ vmware ของเราดูเหมือนว่าฉันเข้าใจผิด ซีพียูของเราถูกตั้งค่าไว้ที่ 2.6GHz ไม่ใช่ 4.6 GHz ฉันได้แก้ไขข้อมูลข้างต้นแล้ว

แก้ไข:

เราพยายามที่จะตั้งค่าเครือข่ายบางส่วนที่เกี่ยวข้องตามนี้vmwarekbและคู่มือ นอกจากนี้เรายังเพิ่ม 4 คอร์เพิ่มเติมให้กับ VM การใช้ CPU ยังคงเหมือนเดิม

ตามที่กล่าวถึงครั้งสุดท้ายที่คุณถามคำถามนี้การรอคอยสูงสุดของคุณคือ ASYNC_NETWORK_IO SQL Server นั่งรอเครื่องที่ปลายอีกด้านของท่อเพื่อแยกย่อยผลลัพธ์การสืบค้นในแถวถัดไป

ฉันได้รับข้อมูลนี้จากผลการรอสถิติของ sp_Blitz (ขอบคุณสำหรับการวางใน):

1 - ASYNC_NETWORK_IO - รอคอย 225.9 ชั่วโมง, รอเวลาเฉลี่ย 143.5 นาทีต่อชั่วโมง, รอสัญญาณ 0.2%, รองาน 2146022 คน, รองานเฉลี่ย 378.9 ms

อย่าปิดการแก้ไขปัญหาเธรด CPU - ไม่เกี่ยวข้อง เน้นประเภทการรอครั้งแรกของคุณและสิ่งที่จะทำให้ประเภทการรอนั้น

หากต้องการแก้ไขปัญหานี้เพิ่มเติมให้เรียกใช้sp_WhoIsActiveหรือsp_BlitzFirst (ข้อจำกัดความรับผิดชอบ: ฉันเป็นหนึ่งในผู้แต่งนั้น) - ทั้งสองอย่างนี้จะแสดงรายการข้อความค้นหาที่ทำงานอยู่ในปัจจุบัน ดูที่คอลัมน์ข้อมูลรอค้นหาข้อความค้นหาที่รอ ASYNC_NETWORK_IO และดูแอปและเซิร์ฟเวอร์ที่พวกเขากำลังเรียกใช้

จากตรงนั้นคุณสามารถลอง:

• การตรวจสอบเพื่อดูว่าเซิร์ฟเวอร์แอปเหล่านั้น underpowered (เช่นถ้าพวกเขา maxed out บน CPU หรือเพจไปยังดิสก์) และปรับพวกเขา
• ทำงานร่วมกับนักพัฒนาแอปเพื่อดูว่าพวกเขากำลังทำการประมวลผลแบบแถวต่อแถวกับผลลัพธ์หรือไม่ (เช่นทุกแถวที่กลับมาจาก SQL Server แอปจะหยุดทำงานและประมวลผลบางอย่างก่อนจะขอผลลัพธ์แถวถัดไป)
• ทำงานร่วมกับนักพัฒนาแอปเพื่อเลือกข้อมูลน้อยลง (เช่นแถวน้อยลงหรือคอลัมน์น้อยลงหากพวกเขาไม่ต้องการข้อมูลทั้งหมด - บางครั้งคุณเห็นสิ่งนี้เมื่อคนเลือก SELECT * โดยไม่ตั้งใจและนำข้อมูลกลับมามากกว่าที่พวกเขาต้องการ ทุกแถวเมื่อต้องการเพียง 1,000 อันดับแรกเท่านั้น

อัปเดตด้วย sp_WhoIsActive - ในสกรีนช็อต sp_WhoIsActive ที่คุณโพสต์คุณมีข้อความค้นหาสองสามข้อความที่กำลังรอ ASYNC_NETWORK_IO สำหรับผู้ที่อ้างถึงคำแนะนำข้างต้น

ในส่วนที่เหลือของข้อความค้นหาให้ดูที่คอลัมน์ "สถานะ" ของ sp_WhoIsActive ส่วนใหญ่จะเป็น "หลับ" นั่นหมายความว่าพวกเขาไม่ได้ทำงานเลย - พวกเขากำลังรอแอพที่ปลายอีกด้านของไพพ์เพื่อส่งคำสั่งถัดไปของพวกเขา พวกเขามีธุรกรรมเปิดอยู่ (ดูที่คอลัมน์ "open_tran_count") แต่ไม่มีสิ่งใดที่ SQL Server สามารถทำได้เพื่อเพิ่มความเร็วในการทำธุรกรรมในโหมดสลีป ข้อความค้นหาเหล่านี้เปิดมานานกว่าสี่สิบนาที (คอลัมน์แรกใน sp_WhoIsActive พวกเขาไม่ได้ทำอะไรอีกแล้วคุณต้องให้คนเหล่านั้นทำธุรกรรมและปิดการเชื่อมต่อนี่ไม่ใช่ปัญหาการปรับแต่งประสิทธิภาพ

ทุกสิ่งที่เราเห็นที่นี่ชี้ไปที่สถานการณ์ที่เรากำลังรอคอยแอพ

เพื่อ anwer คำถามของฉันเอง ASYNC_NETWORK_IO จริง ๆ แล้วไม่ใช่ปัญหาจริง เราแก้ไขปัญหาประสิทธิภาพการทำงานของเราโดยทำตามคู่มือนี้สำหรับปริมาณงานที่มีความละเอียดอ่อน

วิธีปฏิบัติที่ดีที่สุดสำหรับการปรับประสิทธิภาพของเวิร์กโหลดที่มีความอ่อนไหว - แฝงใน vSphere VMs

ฉันทำเครื่องหมายการตั้งค่าที่เราใช้กับระบบของเราด้วยสีเหลืองที่นี่:

ผมคิดว่าการตั้งค่าที่มีผลกระทบมากที่สุดคือการกำหนดค่า Numaและการตั้งค่าความไวแฝงไปสูง ซึ่งทั้งสองสิ่งจำเป็นในการอธิบายจัดสรร / จองแกน CPU จริงและ RAM สำหรับ VM

นอกจากนี้เรายังเพิ่มแกนเพิ่มเติมให้กับ VM และตอนนี้จำเป็นต้องอัปเกรดใบอนุญาต SQL Server ของเราจาก Standard เป็น Enterprise

ดูเหมือนว่า Windows กำลังรายงานความเร็วสัญญาณนาฬิกาของคอร์ CPU 4.6Ghz ของคุณที่น่าพอใจเป็น 2.6Ghz ... ฉันจะเรียกใช้เครื่องมืออย่าง CPU-Z เพื่อตรวจสอบความเร็วที่พวกเขาใช้งานจริงแล้วดูการเปลี่ยนการตั้งค่าพลังงานใน ทั้ง Windows และ BIOS / Management OS เพื่อปิดใช้งานการตั้งค่าการประหยัดพลังงานใด ๆ ที่อาจทำให้คอร์ของคุณมีความเร็วต่ำลง