ปัญหาประสิทธิภาพการทำงานที่แปลกกับ SQL Server 2016

เรามีอินสแตนซ์เดียวของ SQL Server 2016 SP1 ที่ทำงานในเครื่องเสมือน VMware มันมี 4 ฐานข้อมูลสำหรับแต่ละแอปพลิเคชันที่แตกต่างกัน แอปพลิเคชั่นเหล่านั้นล้วน แต่อยู่บนเซิร์ฟเวอร์เสมือนแยกกัน ยังไม่มีการใช้งานจริง ผู้คนที่ทดสอบแอพพลิเคชั่นกำลังรายงานปัญหาด้านประสิทธิภาพ

นี่คือสถิติของเซิร์ฟเวอร์:

• 128 GB RAM (หน่วยความจำสูงสุด 110GB สำหรับ SQL Server)
• 4 คอร์ที่ 4.6 GHz
• การเชื่อมต่อเครือข่าย 10 GBit
• ที่เก็บข้อมูลทั้งหมดใช้ SSD
• ไฟล์โปรแกรมไฟล์บันทึกไฟล์ฐานข้อมูลและ tempdb อยู่บนพาร์ติชันแยกต่างหากของเซิร์ฟเวอร์
• asd

ผู้ใช้ทำการเข้าถึงหน้าจอเดียวผ่านแอปพลิเคชัน ERP ที่ใช้ C ++

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

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

อ้างอิงกับพอล Randal ของ " บอกฉันที่มันเจ็บ " แบบสอบถาม 50% ASYNC_NETWORK_IOของเหตุการณ์ที่รอทุกคนมี

นี่อาจหมายถึงปัญหาเครือข่ายหรือปัญหาด้านประสิทธิภาพของแอพพลิเคชันเซิร์ฟเวอร์หรือไคลเอนต์ ไม่ว่าจะใช้ทรัพยากรจากระยะไกลในระดับความจุสูงสุด เวลาส่วนใหญ่ของ CPU อยู่ที่ประมาณ 26% สำหรับทุกเครื่อง (ไคลเอนต์, เซิร์ฟเวอร์แอป, เซิร์ฟเวอร์ฐานข้อมูล)

เวลาแฝงของการเชื่อมต่อเครือข่ายอยู่ที่ประมาณ 1-3ms IO ของเซิร์ฟเวอร์ db คือความเร็วการเขียนสูงสุดที่ 20MB / s ในระหว่างการใช้งานปกติกับแอปพลิเคชัน (avg คือ 7-9MB / s) เมื่อฉันทดสอบความเครียดฉันได้รับสูงสุด 5GB / s

ขนาดแคชบัฟเฟอร์เท่ากับ 60GB สำหรับฐานข้อมูลของระบบ ERP ของเรา, 20GB สำหรับซอฟต์แวร์ทางการเงินของเรา, 1GB สำหรับซอฟต์แวร์ประกันคุณภาพ, 3GB สำหรับระบบจัดเก็บเอกสาร

ฉันให้บัญชีที่เหมาะสมที่จะใช้ SQL Server ทันทีไฟล์เริ่มต้น แต่นั่นไม่ได้เพิ่มประสิทธิภาพเพียงเล็กน้อย

อายุขัยของเพจอยู่ที่ประมาณ 15k + ในระหว่างการใช้งานปกติ ลดลงไปประมาณ. 05k ในช่วงสิ้นสุดการทดสอบความเครียดหนักซึ่งคาดว่าจะได้ ชุด / วินาทีอยู่ที่ประมาณ 2-8k ขึ้นอยู่กับปริมาณงาน

ฉันว่าแอพ ERP นั้นเขียนได้ไม่ดี แต่ฉันทำไม่ได้เพราะแอปพลิเคชันทั้งหมดได้รับผลกระทบ แม้ในปริมาณงานที่น้อยที่สุด

แต่ฉันไม่สามารถระบุได้ว่าอะไรเป็นสาเหตุของเรื่องนี้ มีเคล็ดลับคำแนะนำแบบฝึกหัดแอปพลิเคชันเอกสารการปฏิบัติที่ดีที่สุด / แย่ที่สุดหรือสิ่งอื่นใดที่คุณคิดเกี่ยวกับปัญหานี้หรือไม่?

นี่คือผลลัพธ์จากsp_BlitzFirst:

ฉันวิ่งไป 600 วินาที ฉันเริ่มมันในช่วงที่มีปริมาณงานของแอพสูง 1/3 ASYNC_NETWORK_IOของเวลาที่มันเป็น ฉันยังผ่านการทดสอบการเชื่อมต่อเครือข่ายที่มีNTttcp, PsPing, และipferf3 pathpingไม่มีอะไรผิดปกติ เวลาตอบสนองอยู่ที่สูงสุด 3ms, เฉลี่ย 0.3ms ปริมาณงานอยู่ที่ประมาณ 1,000 MB / s

การตรวจสอบของฉันส่งผลASYNC_NETWORK_IOให้เกิดการรอคอยอันดับหนึ่งเสมอ

เราตรวจสอบผลลัพธ์ของการปิดใช้งานLarge-Receive-Offloadฟีเจอร์ใน VMware เรายังคงทดสอบอยู่ แต่ผลลัพธ์ดูเหมือนจะไม่สอดคล้องกัน 'มาตรฐาน' ครั้งแรกของเราส่งผลให้มีระยะเวลา 19 นาที (ผลลัพธ์สูงสุดคือ 13 นาทีซึ่งจะทำได้ก็ต่อเมื่อแอปทำงานบน VM ด้วย SQL Server เท่านั้น) ผลลัพธ์ที่สองคือ 28 นาทีซึ่งแย่จริงๆ

ผลลัพธ์แรกของ 'มาตรฐาน' ของเราคือ 19 นาที สิ่งไหนดี. เนื่องจากผลลัพธ์สูงสุดคือ 13 นาที (ซึ่งสามารถทำได้เฉพาะเมื่อเกณฑ์มาตรฐานของแอปพลิเคชันบน VM ด้วย SQL Server เอง) คำแนะนำนี้มีความสำคัญสำหรับปัญหาที่เกี่ยวข้องกับเครือข่าย หรือมีปัญหากับการกำหนดค่า VMware

ฉันกำลังหลงทางในสิ่งที่วิธีการใช้เพื่อตอกตะปูลงไปที่คอขวด

ประสิทธิภาพสูงสุดของแอพสามารถทำได้เมื่อแอพทำงานบน VM ด้วย SQL Server เท่านั้น หากแอปพลิเคชันดำเนินการบน VM หรือเดสก์ท็อปเสมือนระยะเวลามาตรฐานของเราจะเพิ่มเป็นสามเท่า (จากระยะเวลา 13 นาทีถึง 40 นาทีหรือมากกว่า) ปลายทางทั้งหมด (VM ของ SQL Server, VM ของแอปเซิร์ฟเวอร์และเดสก์ท็อปเสมือน) กำลังใช้ฮาร์ดแวร์ทางกายภาพเดียวกัน เราย้ายจุดสิ้นสุดอื่น ๆ ทั้งหมดไปยังฮาร์ดแวร์อื่นแล้ว

แก้ไข: ดูเหมือนว่าปัญหาจะกลับมา หลังจากตั้งค่าโหมดประหยัดพลังงานจากสมดุลจนถึงประสิทธิภาพสูงเราจริง ๆ ปรับปรุงการตอบสนองครั้ง dramtically แต่วันนี้ฉันวิ่ง sp_BlitzFirst อีกครั้งด้วยตัวอย่าง 300 วินาที นี่คือผลลัพธ์ที่ได้:

มันแสดงเวลารอคอยที่สองสำหรับ ASYNC_NETWORK_IO มากกว่าวินาที sp_blitz ที่ทำงานครั้งแรก

หากการรอหลักของคุณคือASYNC_NETWORK_IOแสดงว่าไม่มีปัญหากับ SQL Server เป็นเพราะคอขวดของแอปพลิเคชัน ฉันไม่ได้หมายถึงคอขวดในแอพพลิเคชันเซิร์ฟเวอร์ แต่เป็นคอขวดในแอปพลิเคชัน

คอขวดของแอปพลิเคชันมักเป็นเพราะการประมวลผลแบบแถวต่อแถวในขณะที่ SQL Server กำลังส่งข้อมูล:

• แอปพลิเคชันกำลังขอข้อมูลจาก SQL Server
• SQL Server กำลังส่งข้อมูลอย่างรวดเร็ว
• แอปพลิเคชันแจ้งให้ SQL Server รอในขณะที่ดำเนินการแต่ละแถว
• SQL Server บันทึกเวลารอในASYNC_NETWORK_IOขณะที่แอปพลิเคชันบอกให้รอ

แทนที่จะใช้แอปพลิเคชันจะต้องใช้ข้อมูลทั้งหมดจาก SQL Server และจากนั้นทำการประมวลผลแบบแถวต่อแถว SQL Server อยู่นอกรูปภาพในตอนนั้น

sp_BlitzFirst เอาท์พุต

การLCK_M_Sรอไม่สูง มีเพียง 2 วินาทีของตัวอย่าง 30 วินาทีเท่านั้นที่อยู่ในนั้นและค่าเฉลี่ยของมันคือเพียง 400ms นั่นเป็นเรื่องที่ไม่น่าเป็นไปได้มากที่จะเป็นปัญหา ASYNC_NETWORK_IOคือสุดยอดของคุณในตัวอย่างนั้น ยังคงเป็นปัญหาแอปพลิเคชัน หากคุณต้องการความช่วยเหลือเกี่ยวกับLCKสิ่งต่างๆเราจะต้องดูคำถามที่เกี่ยวข้อง

แม้ASYNC_NETWORK_IOจะไม่ได้แย่ขนาดนั้นในตัวอย่างนั้น ดวงตาของฉันใหญ่เมื่อเวลารอเท่ากับหรือมากกว่าขนาดตัวอย่าง นั่นคือเมื่อฉันขุด

ASYNC_NETWORK_IOปัญหาทั้งหมดของคุณคือ นี่ไม่ใช่ปัญหาของเซิร์ฟเวอร์ SQL เป็นปัญหากับทั้งแอปพลิเคชั่น (ทำการประมวลผลแบบแถวต่อแถวในขณะที่ SQL Server กำลังส่งข้อมูล), แอปพลิเคชันเซิร์ฟเวอร์ (คุณบอกว่าใช้ได้) หรือเครือข่าย (คุณบอกว่าเครือข่ายใช้ได้) ดังนั้นปัญหาอยู่กับแอปพลิเคชัน ต้องแก้ไขแอป C ++

เพื่อที่จะตอบคำถามของฉันเอง: เหตุผลหลักสำหรับ ASYNC_NETWORK_IO ปรากฏบน SQL Server ของเราเป็นชนิดบนรอคือการที่energy savingการตั้งค่าของ Windows Server ถูกกำหนดให้แทน'balanced' 'high performance'เราได้พูดคุยกับบางส่วนผู้ดูแลระบบเครื่อง VM หลังจากนั้นและพวกเขาทั้งหมดกล่าวว่าที่การตั้งค่านี้ฆ่าประสิทธิภาพ

วิธีแก้ปัญหานี้คือ:

• อย่าติดตั้งตัวควบคุมพลังงานเมื่อติดตั้งเซิร์ฟเวอร์ windows
• ตั้งค่าโหมดประหยัดพลังงานเป็นประสิทธิภาพสูงสำหรับเซิร์ฟเวอร์ทั้งหมดผ่านนโยบายกลุ่ม

ปัญหา / สถิติอื่น ๆ ทั้งหมดที่เกี่ยวข้องกับ ASYNC_NETWORK_IO เกี่ยวข้องกับแอพ ERP ของเราที่เขียนไม่ดี ขอบคุณทุกคนที่ช่วยฉันแก้ปัญหานี้ความคิดเห็นคำแนะนำและคำแนะนำของคุณยินดีต้อนรับและเป็นประโยชน์มาก!