आमतौर पर हमारे साप्ताहिक पूर्ण बैकअप लगभग 35 मिनट में समाप्त हो जाते हैं, दैनिक अंतर बैकअप के साथ ~ 5 मिनट में समाप्त होता है। मंगलवार से दैनिकों को पूरा होने में लगभग 4 घंटे लग गए हैं, जिस तरह से आवश्यकता से अधिक होना चाहिए। संयोग से, यह तब से शुरू हुआ जब हमने एक नया SAN / डिस्क कॉन्फिगर किया।
ध्यान दें कि सर्वर उत्पादन में चल रहा है और हमारे पास कोई समग्र समस्या नहीं है, यह सुचारू रूप से चल रहा है - केवल मुख्य रूप से बैकअप प्रदर्शन में प्रकट होने वाले IO समस्या को छोड़कर।
बैकअप के दौरान dm_exec_requests को देखते हुए, बैकअप लगातार ASYNC_IO_COMPLETION पर प्रतीक्षा कर रहा है। अहा, तो हम डिस्क विवाद है!
हालांकि, न तो एमडीएफ (लॉग स्थानीय डिस्क पर संग्रहीत किए जाते हैं) और न ही बैकअप ड्राइव में कोई गतिविधि है (IOPS ~ = 0 - हमारे पास बहुत सारी मेमोरी है)। डिस्क कतार की लंबाई ~ = 0 भी। सीपीयू 2-3% के आसपास होता है, कोई समस्या नहीं है।
SAN एक डेल MD3220i है, LUN जिसमें 6x10k SAS ड्राइव है। सर्वर दो भौतिक रास्तों के माध्यम से SAN से जुड़ा है, प्रत्येक SAN के लिए निरर्थक कनेक्शन के साथ एक अलग स्विच के माध्यम से जा रहा है - कुल चार पथ, उनमें से दो किसी भी समय सक्रिय हो रहे हैं। मैं यह सत्यापित कर सकता हूं कि दोनों कनेक्शन कार्य प्रबंधक के माध्यम से सक्रिय हैं - लोड को समान रूप से विभाजित करना। दोनों कनेक्शन 1G पूर्ण द्वैध चल रहे हैं।
हम जंबो फ्रेम का उपयोग करते थे, लेकिन मैंने उन्हें यहां किसी भी मुद्दे पर शासन करने के लिए अक्षम कर दिया है - कोई बदलाव नहीं। हमारे पास एक और सर्वर है (वही OS + config, 2008 R2) जो अन्य LUN से जुड़ा है, और यह कोई समस्या नहीं दिखाता है। यह हालांकि SQL सर्वर नहीं चला रहा है, लेकिन उनमें से शीर्ष पर केवल CIFS साझा कर रहा है। हालाँकि, इसके LUN में से एक पसंदीदा मार्ग परेशानी SAN के रूप में उसी SAN कंट्रोलर पर है - इसलिए मैंने उस पर भी फैसला सुनाया है।
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.ये समान SAN / नियंत्रक पर चल रहे गैर-समस्याग्रस्त CIFS सर्वर पर भी होते हैं, और मेरे Googling से वे गैर-महत्वपूर्ण लगते हैं।
ध्यान दें कि सभी सर्वर अप-टू-डेट ड्राइवरों के साथ एक ही एनआईसी - ब्रॉडकॉम 5709 सी का उपयोग करते हैं। सर्वर खुद डेल R610 के हैं।
मुझे यकीन नहीं है कि आगे के लिए क्या जांचना है। कोई सुझाव?
अपडेट - रनिंग परफॉमन
मैंने औसत रिकॉर्डिंग की कोशिश की। बैकअप करते समय डिस्क सेक / रीड एंड परफेक्ट काउंटर। बैकअप धधकते हुए शुरू होता है, और फिर मूल रूप से 50% पर मृत हो जाता है, धीरे-धीरे 100% की ओर रेंगता है, लेकिन 20x समय लेना चाहिए।
दोनों सैन पथ का उपयोग किया जा रहा दिखाता है, फिर छोड़ रहा है।
बैकअप 15:38:50 के आसपास शुरू हुआ - सभी को अच्छी लग रही नोटिस, और फिर चोटियों की एक श्रृंखला है। मुझे लेखन से कोई सरोकार नहीं है, केवल पढना ही फाँसी लगता है।
/ बंद पर बहुत कम कार्रवाई पर ध्यान दें, हालांकि बहुत अंत में प्रदर्शन धमाकेदार।
एक 12sec अधिकतम नोट करें, हालांकि औसत कुल मिलाकर अच्छा है।
अद्यतन - एनयूएल डिवाइस का समर्थन
रीड मुद्दों को अलग करने और चीजों को सरल बनाने के लिए, मैंने निम्नलिखित भाग किया:
BACKUP DATABASE XXX TO DISK = 'NUL'परिणाम बिल्कुल समान थे - एक फट पढ़ने के साथ शुरू होता है और फिर स्टालों, संचालन फिर से शुरू करना और फिर:
अपडेट - IO स्टाल्स में
मैंने शॉन द्वारा सुझाए गए जोनाथन केहियास और टेड क्रुएगर की किताब (पृष्ठ 29) से dm_io_virtual_file_stats क्वेरी चलाई । शीर्ष 25 फाइलों को देखना (एक डेटा फ़ाइल प्रत्येक - सभी परिणाम डेटा फ़ाइलों के रूप में), ऐसा लगता है कि रीड्स लिखने की तुलना में खराब हैं - शायद इसलिए कि राइट सीधे सैन कैश पर जाते हैं जबकि ठंड रीड डिस्क को हिट करने की आवश्यकता होती है - बस एक अनुमान हालांकि ।
अद्यतन - प्रतीक्षा आँकड़े
मैंने कुछ प्रतीक्षा आँकड़े एकत्र करने के लिए तीन परीक्षण किए। प्रतीक्षा आँकड़े ग्लेन बेरी / पॉल रैंडल स्क्रिप्ट का उपयोग करके उद्धृत किए जाते हैं । और बस पुष्टि करने के लिए - बैकअप टेप करने के लिए नहीं किया जा रहा है, लेकिन एक iSCSI LUN को। यदि NUL बैकअप के समान परिणाम हों, तो परिणाम स्थानीय डिस्क के समान होते हैं।
साफ किए गए आँकड़े। 10 मिनट के लिए भाग गया, सामान्य भार:
साफ किए गए आँकड़े। 10 मिनट के लिए दौड़ा, सामान्य लोड + सामान्य बैकअप चल रहा है (पूरा नहीं हुआ):
साफ किए गए आँकड़े। 10 मिनट के लिए दौड़ा, सामान्य लोड + एनयूएल बैकअप चल रहा है (पूरा नहीं हुआ):
अद्यतन - Wtf, ब्रॉडकॉम?
मार्क स्टोरी-स्मिथ के सुझावों और काइल ब्रैंड्स के ब्रॉडकॉम एनआईसी के साथ पिछले अनुभवों के आधार पर, मैंने कुछ प्रयोग करने का फैसला किया। जैसा कि हमें कई सक्रिय रास्ते मिल गए हैं, मैं अपेक्षाकृत आसानी से बिना किसी आउटेज के एनआईसी के कॉन्फ़िगरेशन को एक-एक करके बदल सकता था।
टीओई और बड़े सेंड ऑफलोड को निष्क्रिय करने से लगभग पूर्णता प्राप्त हुई:
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!टीओई विकलांग, एलएसओ सक्षम - अच्छा दिख रहा है:
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).निष्कर्ष में ऐसा लगता है कि सक्षम ब्रॉडकॉम एनआईसीएस टीसीपी ऑफलोड इंजन समस्याओं का कारण है। जैसे ही टीओई अक्षम था, सब कुछ एक आकर्षण की तरह काम करता था। मुझे लगता है मैं आगे जाने वाले किसी भी अधिक ब्रॉडकॉम एनआईसी का आदेश नहीं दे रहा हूं।
अपडेट - डाउन CIFS सर्वर जाता है
आज समान और कामकाजी CIFS सर्वर ने IO अनुरोधों को लटकाना शुरू कर दिया। यह सर्वर SQL सर्वर नहीं चला रहा था, बस सादा विंडोज वेब सर्वर 2008 R2 सीआईएफएस पर शेयरों की सेवा कर रहा था। जैसे ही मैंने उस पर टीओई को निष्क्रिय किया, वैसे ही सब कुछ सुचारू रूप से चलने लगा।
बस पुष्टि करता है कि मैं कभी भी ब्रॉडकॉम एनआईसीएस पर टीओई का उपयोग नहीं करूंगा, अगर मैं ब्रॉडकॉम एनआईसी से बिल्कुल भी नहीं बच सकता।