tempdb के लिए io_stall_writes_ms इतना अधिक क्यों है?

हमारे पास एक ही डिस्क ड्राइव पर उपयोगकर्ता और सिस्टम डेटा फाइलें हैं। (Io_stall_write_ms / (1.0 + num_of_writes)) उपयोगकर्ता फ़ाइलों के लिए 2 से नीचे है, लेकिन अस्थायी फ़ाइलें आमतौर पर 400 से अधिक होती हैं। मुझे लगता है कि कुछ सर्वरों पर और मुझे उत्सुकता है अगर एक कारण है कि इसे tempdb को लिखने में अधिक समय लगता है एक नियमित डेटाबेस डेटा फ़ाइल की तुलना में।

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

धन्यवाद,

sql-server sql-server-2008

स्नैपशॉट या RCSI का उपयोग करना? tempdb डेटा / लॉग फ़ाइलों के रूप में एक ही सरणियों / ड्राइव पर? अन्य फ़ाइलों की तुलना में कितने tempdb को लिखते हैं? अपने दम पर आँकड़ा उस संदर्भ के बिना कुछ हद तक निरर्थक है, जिसमें इसकी उत्पत्ति होती है।

— मार्क स्टोरी-स्मिथ

संक्षिप्त उत्तर: उच्चतर IO स्टालों को देखना अपने आप में एक समस्या हो सकती है या नहीं भी हो सकती है। यदि आपके पास कोई समस्या है, तो आपको अधिक जानकारी के लिए यह देखना होगा। यह थोड़ा अधिक लगता है, हाँ, लेकिन क्या आप पीड़ित हैं? यदि ऐसा है, तो यह संभवतः इसलिए है क्योंकि या तो आपका IO सिस्टम लोड को सही से हैंडल नहीं कर रहा है (क्योंकि यह नहीं हो सकता है, क्योंकि आपके पास एक ड्राइव या किसी अन्य कारण से सब कुछ है) या आप TempDB में बहुत अधिक काम कर रहे हैं (पहली समस्या को बदलना - IO प्रदर्शन - शायद एक आसान और अधिक कुशल फिक्स है, लेकिन पहले निर्धारित करें कि आपको कोई समस्या है)

अब चर्चा / उत्तर:

यहाँ खेलने पर दो सवाल हैं -

1.) जब मैं उच्च आईओ स्टॉल देखता हूं तो मैं क्या करूं?

सबसे पहले, "उच्च" देखने वाले की आंखों में है। यदि आप 10 DBA से पूछते हैं कि IO स्टालों के लिए "बहुत अधिक" क्या है, तो आपको शायद उन संख्याओं के साथ 2-3 अलग-अलग उत्तर मिलेंगे, 5-6 "यह निर्भर करता है" उत्तर और एक खाली घूरना। मेरी धारणा औसतन 400ms की है यहाँ बहुत अधिक है, खासकर जब अन्य DBs औसत स्टाल समय के लिए 2ms या उससे कम हैं।

चाहे जो भी डेटाबेस उच्च स्टालों को देख रहा हो, आपको उसी तरह से संपर्क करना चाहिए। एक IO स्टाल ऐसा लगता है जैसे ... एक IO अपेक्षा से अधिक समय लेने का अनुरोध करता है। ये होते हैं। वे सिस्टम में हर समय साझा और सीमित संसाधनों (वास्तव में हमारे सभी सिस्टम) के साथ होते हैं। वे एक मुद्दा बन जाते हैं जब स्टॉल प्रदर्शन की समस्या बन जाते हैं या उनका नेतृत्व करते हैं। इसलिए मुझे विश्वास है कि आप यहां निगरानी के सक्रिय भाग के रूप में देख रहे हैं या क्योंकि आप प्रदर्शन समस्याओं का अनुभव कर रहे थे जो आप समस्या निवारण कर रहे हैं। हम भी सिर्फ IO स्टालों में खो जाना नहीं चाहते हैं। हम पहेली का एक टुकड़ा देख रहे हैं न कि बड़ी तस्वीर। एसक्यूएल अंतिम बार फिर से शुरू होने के बाद से इंतजार करने या फाइल के आंकड़ों को देखने में परेशानी हो सकती है क्योंकि आप हर समय देख रहे हैं और कुछ रखरखाव विंडो या भारी लोड विंडो काउंटरों को तिरछा कर सकती हैं। इसलिए सुनिश्चित करें कि आप पूरी तस्वीर देखें।

लेकिन जब मुझे संदेह होता है कि मेरे पास डिस्क प्रदर्शन का मुद्दा है या इस तरह से क्वेरी में कुछ बंद है, तो मैं आमतौर पर एक प्रक्रिया का पालन करता हूं जो दिखता है:

सर्वर पर प्रतीक्षा आंकड़ों को देखें। @swasheck ने नीचे दिए गए उत्तर में एक महान लिंक को एक टिप्पणी के रूप में साझा किया । यह आपको SQL सर्वर में प्रतीक्षा आँकड़ों को देखने और उनका विश्लेषण करने के लिए पॉल रैंडल के पोस्ट पर ले जाता है। वहा जाओ। आप किस तरह का इंतजार देख रहे हैं? आप आईओ प्रदर्शन (से संबंधित प्रतीक्षा करता दिखाई दे रहा है PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, आदि?)। यदि आप ऐसा करते हैं तो यह एक और संकेत है कि आपके पास कुछ IO संबंधित प्रदर्शन समस्याएँ हैं, जैसे IO स्टॉल। लेकिन यह आपको यहां समझौते का एक और रूप देता है।
आईओ प्रदर्शन को देखो। विशेष रूप से, पर Physical Disk:Avg Disk Sec/Readऔर Avg Sec Disk Sec/Writeकाउंटर पर परफ्यूम के अंदर देखें । ये आपकी विलंबता को मापते हैं। एक प्रदर्शन लॉग फ़ाइल में सहेजे गए समय में इन काउंटरों को देखें। आपने औसत के लिए क्या देखा? यदि आप 0.020 सेकंड (20ms) से अधिक संख्या देख रहे हैं तो यह एक मुद्दा हो सकता है। यदि आप संख्या 40-50ms से अधिक देखते हैं, तो उच्च या किसी समस्या का अधिक दृढ़ संकेत है। अपने स्पाइक्स को भी देखें? वे कितने ऊंचे स्थान पर जाते हैं और कितने समय तक रहते हैं? यदि आप सैकड़ों ms में स्पाइक्स देखते हैं और वे दसियों या सेकंड या उससे अधिक के स्कोर तक चलते हैं और / या अक्सर होते हैं, तो आपके कार्यभार के लिए आपके IO प्रदर्शन के साथ समस्या होने की अधिक संभावना है।
अपने IO सेटअप को देखें। यह क्या है? स्थानीय डिस्क? सैन? भंडारण सरणी? आपको किस तरह के और IOP से बाहर देखना चाहिए? क्या आप जो करने की कोशिश कर रहे हैं, उसके लिए यह पर्याप्त है? आपने अपने IO को अपने कार्यभार के लिए रेखांकित किया हो सकता है। बस अपने भौतिक स्पिंडल, RAID सेटिंग्स आदि को न देखें, अपने रास्तों को अपने डिस्क पर देखें। क्या आप 1GB लिंक के माध्यम से सब कुछ आगे बढ़ा रहे हैं जिसे आप बहुत सारे अन्य ट्रैफ़िक के साथ साझा कर रहे हैं? क्या आप स्टोरेज के नजरिए से डिस्क परफॉर्मेंस मेट्रिक्स देख सकते हैं।

( नोट: इस प्रतीक्षा आँकड़े विश्लेषण और परफ़ॉर्म विश्लेषण के लिए - विभिन्न अवधियों और उपयोग के प्रकारों को देखें। क्या आपके पास दिन के दौरान रात में अलग-अलग उपयोग के आँकड़े हैं? प्रसंस्करण विंडो? बैच विंडो का रखरखाव? जहाँ आप बहुत सारे अनुक्रमों का पुनर्निर्माण करते हैं? प्रत्येक अवधि के दौरान इन उपकरणों को देखें और समझें कि आप प्रत्येक के लिए क्या देख रहे हैं)

यहाँ एक और IO प्रदर्शन पर विचार -

आपने कहा कि सिस्टम DBs और उपयोगकर्ता DBs साझा किए गए हैं। क्या यह उत्पादन है? यदि ऐसा है, तो यह हमेशा सबसे अच्छा परिदृश्य नहीं होता है। क्या आप भी उसी ड्राइव पर लॉग फाइल और डेटा फाइल शेयर कर रहे हैं? यह सबसे अच्छा परिदृश्य नहीं है। इस भंडारण को और क्या साझा करता है? एक ऐसी दुनिया में जहां आप स्पिंडल और छापे समूहों और डिस्क के बारे में चिंता कर रहे हैं और यह निर्णय करना है कि सबसे अच्छा प्रदर्शन करने वाले डिस्क किसे मिलते हैं, मैं (अंगूठे के एक सामान्य नियम के रूप में) .. जो डीबी दुनिया में होने के लिए महान नहीं हैं लेकिन यह एक सच पकड़ लेता है) मेरी सबसे तेज़ और सबसे अधिक TempDB के लिए समर्पित (उस पर नीचे), फिर लॉग फ़ाइलों, फिर डेटा फ़ाइलों के साथ। एक ऐसी दुनिया में जहां आपके पास एक डिवाइस पर डिस्क का एक बड़ा ढेर है जैसे कि नेटएप, डेल इक्वल लॉजिक या ईएमसी वीएनएक्स, इत्यादि।

2.) क्या कुछ कारण हैं TempDB अधिक हो सकता है?

तो TempDB एक डेटाबेस है और इसमें IO स्टॉल हो सकते हैं जैसे कि किसी अन्य डेटाबेस की तरह मैंने अभी चर्चा की है। लेकिन क्या कुछ कारण हैं TempDB उच्च पढ़ सकते हैं? (संपूर्ण नहीं, मैं संपादन, अन्य उत्तरों या टिप्पणियों में परिवर्धन या विचारों का स्वागत करता हूं) -

आपके कोड के कारण - क्या आप अपने कोड में TempDB का उपयोग उद्देश्यपूर्ण तरीके से कर रहे हैं? बहुत सारे अस्थायी टेबल और टेबल चर बनाए और नष्ट कर दिए गए? TempDB में इस तरह से बहुत सारी चीजें करना? यह बुरा या जरूरी नहीं है, लेकिन आप इसे देख सकते हैं और अपने जानबूझकर TempDB उपयोग पैटर्न को समझ सकते हैं।
TempDB एक साझा वर्कहॉर्स है - TempDB एक डेटाबेस है जिसका उपयोग उपयोगकर्ता द्वारा परिभाषित अस्थायी वस्तुओं और विभिन्न कार्य तालिकाओं और आपके संपूर्ण SQL उदाहरण द्वारा उपयोग किए जाने वाले संचालन के लिए एक अस्थायी स्थान के रूप में किया जाता है। कितने उपयोगकर्ता DB हैं? आप सामान्य रूप से किस तरह का कार्यभार देखते हैं? TempDB सभी चीजों को साझा करने के लिए एक संसाधन है।
अकुशल प्रश्न और अपर्याप्त स्मृति - शायद ऐसे प्रश्न हैं जो अनुक्रमणिका का पर्याप्त रूप से उपयोग नहीं कर रहे हैं या बड़े स्कैन और क्रमबद्ध संचालन कर रहे हैं। बड़े हैश ऑपरेशन, और सर्वर पर मेमोरी इन के लिए पर्याप्त नहीं है। ये ऑपरेशन पर्दे के पीछे कार्यस्थलों के रूप में TempDB के लिए "फैल" होगा। कभी-कभी आपकी क्वेरी योजनाओं और अनुक्रमण या क्वेरी ट्यूनिंग को देखने के साथ इसे टाला जा सकता है। कभी-कभी ऐसा होता है (गोदाम के वर्कलोड पर अधिक, मुझे लगता है)। यदि आपके पास पर्याप्त मेमोरी है, तो यह मदद कर सकता है, लेकिन ये प्रश्न अभी भी कई बार फैल सकते हैं। इसे भी देखें।
क्या आप अपने सिस्टम में अद्यतित संख्या के साथ पढ़े हुए स्नैपशॉट अलगाव स्तर का उपयोग कर रहे हैं? इसके परिणामस्वरूप TempDB गतिविधि में वृद्धि हो सकती है।

मुद्दा यह है - TempDB बहुत तरीकों से उपयोग किया जाता है, और यह मुझे सबसे ज्यादा आश्चर्यचकित नहीं करता है कि इसे अपने व्यस्ततम में से एक के रूप में देखें, यदि सबसे व्यस्त, डेटाबेस नहीं। जब मैं इसे किसी ग्राहक की साइट पर सभी डेटाबेस की उच्चतम संख्या और उच्चतम औसत स्टॉल के रूप में देखता हूं तो यह मुझे आश्चर्यचकित नहीं करता है। यह कभी-कभी इसके कार्यभार का स्वरूप होता है। जिन चीज़ों का मैंने यहाँ उल्लेख किया है उनमें से कुछ को देखकर निश्चित रूप से यह निर्धारित करने में मदद मिल सकती है कि क्या ये संख्याएँ किसी समस्या का संकेत देती हैं और यदि हां, तो इसे हल करने में गहराई तक कैसे जाएँ।

— माइक वाल्श
स्रोत

-4

TempDB उदाहरण पर सभी डेटाबेस के बीच साझा किया गया है। तो कभी-कभी कुछ पृष्ठों के लिए TempDB के भीतर विवाद हो सकता है: SGAM , GAM , और PFS । संक्षेप में, ये पृष्ठ अब तक TempDB में क्या उपयोग किया गया है, का ट्रैक रखते हैं, और जहां नए उपयोग के लिए स्थान उपलब्ध है।

आमतौर पर, TempDB में कई डेटा फ़ाइलों को जोड़कर इससे निपटा जाता है। सही संख्या के अनुसार कुछ अलग दर्शन हैं, लेकिन सभी सहमत हैं कि आपके पास एक से अधिक होना चाहिए।

यहाँ कुछ सवाल चलाने के लिए कर रहे हैं ...

यह आपको दिखाएगा कि TempDB के पास कितनी फाइलें हैं और वे कहाँ स्थित हैं।

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

यह आपको दिखाएगा कि आपके पास कितने सीपीयू और कोर हैं।

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

यह आपको दिखाएगा कि आपके पास कितने NUMA नोड्स और कोर NUMA नोड हैं।

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

यह आपको दिखाएगा कि TempDB में कौन से पृष्ठ प्रतीक्षा कर रहे हैं।

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

यहाँ एक लेख है जो पृष्ठ विवाद मुद्दे पर थोड़ा और गहराई में जाता है।

ठीक है, तो अब दर्शन भाग ... :-)

खुद के लिए, अगर मैं एक एसएमपी प्रणाली पर हूं, तो मैं केवल कुल कोर के रूप में कई फाइलें चाहता हूं ।

अगर मैं NUMA सिस्टम पर हूं , तो मुझे केवल NUMA नोड के अनुसार अधिक से अधिक फाइलें चाहिए ।

हालाँकि, मैं शायद ही कभी TempDB के लिए चार फ़ाइलों को और अधिक होने के लिए कोई सुधार देखता हूँ। इसलिए मैं आमतौर पर चार और निगरानी विवाद से शुरू करता हूं जैसा कि मैंने जिस लेख से जोड़ा था, उसमें बताया गया है।

अगर मुझे समस्याएं दिखती हैं, तो मैं दो और जोड़ूंगा। फिर से जांच करें, अधिक जोड़ें, और तब तक दोहराएं जब तक कि विवाद गायब न हो जाए।

— स्टीवन
स्रोत

-1 क्षमा करें, यहाँ FUD का एक उचित भाग भी है। GAM / SGAM / PFS कॉन्टेस्ट कुंडी विवाद के रूप में प्रकट होता है, यह विस्तारित IO प्रतीक्षा में परिणाम नहीं होने वाला है, जो कि ओपीएस प्रश्न का फोकस है।

— मार्क स्टोरी-स्मिथ

यह ब्लॉग regurg का एक अच्छा सौदा की तरह लग रहा है। इस बिंदु पर, सबसे बड़ा मुद्दा यह है कि सब कुछ एक ही धुरी को मार रहा है। किसी भी डेटाबेस सिस्टम में IO लगभग हमेशा सबसे बड़ी अड़चन होती है और जब आप एक ही डिस्क (संभवतः एक ही धुरी) पर सब कुछ टकराते हैं तो आपका कुल इंतजार आसमान छूने वाला होता है। मैं वास्तव में 'वेट्स एंड क्यूज़' के लिए Google / बिंग खोज की सलाह दूंगा ताकि इस IO अड़चन को सत्यापित और मात्राबद्ध किया जा सके। इस तरह ओपी सेवा मालिकों के पास वापस जा सकता है और डिस्क के लिए $ $ और पुश का उपयोग करने के लिए डाउनटाइम कर सकता है।

— स्वैसे

यहां से

— स्वैसे

@ मर्क - स्पष्टीकरण के लिए धन्यवाद। मैं प्रतिक्रिया की सराहना करता हूं।

— स्टीवन