हाइपरथ्रेडिंग को अक्षम करने से हमारे SQL सर्वर इंस्टाल पर प्रदर्शन में सुधार होगा


28

संबंधित: SQL सर्वर और हाइपरथ्रेडिंग पर वर्तमान ज्ञान

हाल ही में हमने अपने Windows 2008 R2 डेटाबेस सर्वर को X5470 से X5560 में अपग्रेड किया । सिद्धांत दोनों CPU में बहुत समान प्रदर्शन है, अगर कुछ भी X5560 थोड़ा तेज है।

हालाँकि, SQL Server 2008 R2 प्रदर्शन पिछले दिन या तो बहुत बुरा रहा है और CPU उपयोग बहुत अधिक है।

पृष्ठ जीवन प्रत्याशा बड़े पैमाने पर है, हम पृष्ठों के लिए लगभग 100% कैश हिट कर रहे हैं, इसलिए मेमोरी कोई समस्या नहीं है।

जब मैं भागा:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

मुझे मिला:

Wait_type इंतज़ार_टूक_काउंट wait_time_ms max_wait_time_ms सिग्नल_वाइट_टाइम_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 पंक्ति) प्रभावित

मैं भी भागा

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

और पा लिया

Wait_type Wait_time_s pct रनिंग_पक्ट
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

यह समानता (उच्च CXPACKET) से जुड़े प्रश्नों को सिंक्रनाइज़ करने में भारी मात्रा में दिखाता है। इसके अतिरिक्त, कई समस्याओं में से कई को कई कोर पर निष्पादित किया जा रहा है (हमारे कोड में कहीं भी MAXDOP संकेत नहीं हैं)

एक या दो दिन से अधिक समय तक सर्वर लोड नहीं रहा। हम क्वेरी निष्पादन के साथ बड़ी मात्रा में विचरण का अनुभव कर रहे हैं, आमतौर पर कई प्रश्न धीमे प्रतीत होते हैं कि वे हमारे पिछले DB सर्वर पर थे और CPU वास्तव में उच्च है।

हमारे CPU उपयोग को कम करने और थ्रूपुट को बढ़ाने में हाइपरथ्रेडिंग मदद को अक्षम करेगा?



ध्यान रखें कि CXPACKET का मतलब यह नहीं है कि प्रक्रियाओं के एक साथ विलय होने की प्रतीक्षा में बहुत समय है। CXPACKET का अर्थ है कि धागा अपने प्रसंस्करण को समाप्त करने के लिए दूसरे धागे की प्रतीक्षा कर रहा है। आपको एक विशिष्ट क्वेरी को देखने की जरूरत है जिसमें CXPACKET प्रतीक्षा में एक धागा है और देखें कि CXBACKET के अलावा अन्य धागे क्या इंतजार कर रहे हैं। यह आमतौर पर IO या नेटवर्क है। ऊपर के आउटपुट में आप लैच पर इंतजार कर रहे हैं और डिसाइड किया जा रहा है। कुछ क्वेरी को ट्यून करने की आवश्यकता है, या आपको यह देखने की आवश्यकता है कि कुंडी क्यों ली जा रही है।
मर्डनी

हमारे मामले में, CXPACKET उच्च था क्योंकि अन्य धागे केवल कैश से अत्यधिक पढ़ रहे थे (प्रति क्वेरी 20 मिलियन तार्किक रीड्स)। हमारा मामला, फिर से, एक विभाजन तालिका के साथ एक बुरा विरोधी अर्धविराम था जो केवल 700K पंक्तियों का था।
ओजामोरा

@ मर्डनी, हाँ उच्च कुंडी प्रतीक्षा समय के विषय में हम इस समय इसकी जाँच कर रहे हैं।
सैम केसर

जवाबों:


10

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

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


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

3
मुझे यकीन है कि आप एक उत्पादन प्रणाली के साथ 'प्लेइंग' से बचना चाहते हैं, एक आदर्श दुनिया में हम सभी के पास उस कारण से उत्पादन के समान परीक्षण वातावरण होगा। मैं अटकलें पर उत्पादन में बदलाव नहीं करने के लिए सहमत हूं। हालांकि, मैं अपने जवाब से खड़ा हूं: विशिष्ट वर्कलोड का परीक्षण करना किसी भी तैनाती का एक महत्वपूर्ण हिस्सा है और जो भी आपको अलग-अलग बताता है वह एक चार्टेटन है। मेरे लिए, सभी संकेत हाइपरथ्रेडिंग के लिए एक समस्या होने की ओर इशारा करते हैं, लेकिन हम पूरे दिन और पूरी रात चीजों के बारे में बात कर सकते हैं और निश्चित रूप से जानने के लिए अभी भी केवल एक ही रास्ता है।
रोब मोइर

5
यहाँ देखें - मैं उत्तर से सहमत हूँ। सामान्य उत्तर है: हाइपरथ्रेडिंग बंद करें। अधिक विशिष्ट उत्तर है: यह विशिष्टताओं पर निर्भर करता है और जरूरी परीक्षण किया जाना चाहिए।
टॉमटॉम

1
अजीब तरह से पर्याप्त है, मुझे लगता है कि यह स्वीकार करने के लिए सबसे अच्छा जवाब है, मैक्सडॉप सेटिंग्स के साथ घूमने से बहुत परेशानी हो सकती है, नेहेल्म सीपीयू कोर आधारित xeons की तुलना में बहुत तेज़ होते हैं यहां तक ​​कि हल्के से धीमी गति से भी, मुझे लगता है कि एल 2 कैश्ड तर्क थोड़ा सा हैं लाल हेरिंग के कारण l3 कैश इतना बड़ा होता है। एक परिशिष्ट के रूप में देखें: blog.stackoverflow.com/2010/10/database-upgrad , अगर किसी को 20% से अधिक हिट / लाभ दिखाई दे रहा है ... तो शायद एचटी के कारण नहीं।
सैम केसर

मुझे @TomTom और @Robert के विपरीत अनुभव हुआ है। मैंने पाया है कि एचटी ऑन आमतौर पर 10-15% बेहतर है। वह अवसर जहां इसे बंद करने से प्रदर्शन में सुधार होता है, वास्तव में दुर्लभ है।
ब्रायन नोब्लुच

12

मैं उससे सहमत हूं

  • पर सबसे अच्छा सिफारिश "अपने काम का बोझ पर हाइपरथ्रेडिंग कोशिश और देखो क्या होता है"। हम अभी यह कर रहे हैं क्योंकि मैं टाइप करता हूं, और यह अच्छा नहीं है!
  • आपको शायद हमेशा हाइपरथ्रेडिंग डिसेबल के साथ शुरू करना चाहिए, क्योंकि यह सबसे सुरक्षित है

ऐसा लगता है कि हमें दो चीजों को ट्यून करना चाहिए:

  1. मैक्सडॉप (अधिकतम समानता का डिग्री)। मैंने जो कुछ पढ़ा है वह इंगित करता है कि यह निर्बाध होना एक बुरा विचार है, और Microsoft प्रलेखन कहता है:

    इस विकल्प को स्थापित करना [MAXDOP] एक बड़े मूल्य [8 से] अक्सर अवांछित संसाधन खपत और प्रदर्शन में गिरावट का कारण बनता है।

    से अधिक कुछ भी 8आमतौर पर अनुशंसित नहीं है .. इसलिए मैंने इसे 4अभी के लिए निर्धारित किया है । यह शुरू में शून्य (अनबाउंड) था।

  2. समानांतरता के लिए लागत थ्रेसहोल्ड। जाहिरा तौर पर 5यहाँ के डिफ़ॉल्ट को कुछ SQL MVP पोस्ट मैंने पाया है के अनुसार काफी कम डिफ़ॉल्ट माना जाता है - हम इसे कम करने के लिए ट्यून कर सकते हैं कि शेड्यूलर द्वारा कितना समानतावाद का प्रयास किया गया है।

लेकिन ईमानदारी से ये वर्कअराउंड की तरह महसूस करते हैं; मुझे लगता है कि हमारे कार्यभार (पूर्ण-पाठ सूचकांक भारी) के लिए सही समाधान HT को अक्षम करना है।


4
MAXDOP भी HT के साथ समस्याएँ पैदा करता है क्योंकि यह एक ही CPU पर दो थ्रेड्स निष्पादित करने का प्रयास कर सकता है यदि आपने कहा है, 8 कोर और 16 थ्रेड्स, और आपका मैक्सडॉप 10 पर सेट है। आम तौर पर प्रति तार्किक प्रोसेसर में अधिकतम MAXDOP अधिकतम होना चाहिए। और एक ही प्रक्रिया के लिए एक ही सीपीयू पर दो थ्रेड निष्पादित करना व्यर्थ की तरह है।
मार्क हेंडरसन

2
@Farseeker केवल तभी होता है जब आपके पास हाइपरथ्रेडिंग-अवेयर ऑपरेटिंग सिस्टम न हो। 2000 की तुलना में नया विंडोज इसके बारे में जानता है।
Mircea Chirea

यह ध्यान देने योग्य है कि ये अधिकतम ओवरराइड केवल परेशानी पैदा कर रहे थे। डिफ़ॉल्ट हमारे लिए ठीक था
सैम सैफ्रन

2
SQL सर्वर का मानक संस्करण अप्रत्यक्ष रूप से बचे रहने पर किसी भी तरह के 4 MAXDOP पर अधिकतम होता है। उससे अधिक जाने के लिए एंटरप्राइज़ की आवश्यकता है। हमारे पास कुछ वर्कलोड हैं जो 1 के MAXDOP (सबसे गैर-एचटी बॉक्स, कई 8 कोर एएमडी को चलाने) के साथ सबसे तेजी से चले गए हैं ...
ब्रायन नोबलाच

1
@Brian Knoblauch - मैं इसे एक साल बाद जानता हूं, लेकिन मैंने इस "SQL सर्वर के मानक संस्करण को 4 किसी भी रास्ते के MAXDOP पर अधिकतम तब छोड़ दिया जब आप बिना किसी दस्तावेज के" किसी भी अवसर को इंगित कर सकते हैं। वर्तमान में हम काम पर MAXDOP का उपयोग करने की बात कर रहे हैं, लेकिन निश्चित नहीं है कि इसे किस पर सेट किया जाए। मूल रूप से इसका मतलब 4 अनबाउंड सही है?
जेरेमी ए। वेस्ट

9

आनंदटेक ने पाया कि शुद्ध रीड लोड के साथ, यह थोड़ा चोट पहुंचाता है, और एक भारी भार के साथ, यह थोड़ी जीत थी। मैंने कुछ भी नहीं देखा है मुझे लगता है कि यह आपको -5% से बहुत अधिक हिट या 15% से बेहतर जीत देगा। ध्यान दें कि एटम के साथ, यह एक बहुत बड़ी जीत है, लेकिन यह एक बहुत ही अजीब सीपीयू है।

आप सभी बदल गया सीपीयू था? आप 12 एमबी कैश और 4 थ्रेड्स से गए, इसलिए 3 एमबी कैश प्रति थ्रेड, 8 एमबी कैश और 8 थ्रेड्स, इसलिए 1 एमबी प्रति थ्रेड। अब, यह ओवरसिंप्लीफाइंग है, लेकिन मैं शर्त लगाता हूं कि जो आपको मार रहा है, आप कैश में क्वेरी चलाते थे, और अब उन्हें रैम से चलाते हैं क्योंकि उन्हें 1 एमबी से अधिक लेकिन 3 एमबी से कम की आवश्यकता होती है। HT को बंद करने से शायद मदद मिलेगी, लेकिन मैं पुराने CPU पर वापस जाऊंगा। HT को बंद करें, और आपको प्रति थ्रेड 2MB मिलता है, लेकिन यदि आपका वर्कलोड इतना अधिक है, तो यह मदद नहीं करेगा। यह अच्छी तरह से हो सकता है कि पुराने 12MB कैश सीपीयू आपके कार्यभार के लिए बहुत तेज़ है।

मैं एचटी को बंद करने की कोशिश करूंगा, और देखूंगा कि क्या यह एक सुधार है, लेकिन मुझे संदेह है कि कैश आपके काम के भार के लिए राजा है, और आपको 12 एमबी चिप पर वापस जाने की आवश्यकता हो सकती है।


3
कोर अवलोकन प्रति L2 कैश एक बड़े पैमाने पर निरीक्षण है , क्योंकि सीपीयू एक पूर्ण पीढ़ी से आगे है (Nehalem / Core i7 बनाम Core 2 Quad class)।
जेफ एटवुड

@Jess, @ रोनाल्ड और नेहेलम के पास L2 कैश बहुत कम है। बल्क L3 है जिसे कोर के पार साझा किया गया है।
माइकेसा चीरा

7

हाइपरथ्रेडिंग, कम से कम, अमूर्त कार्य का एक तरीका है जो ऑपरेटिंग सिस्टम से दूर है और इसे L-L2 और L2 कैश तक सीधी पहुंच के साथ मरने देता है, जो कार्य को तेज गति से स्विच करना आसान बनाता है।

VMWare के साथ परीक्षण ने संकेत दिया है कि एचटी को अक्षम करने से मानक भार के तहत कोई फर्क नहीं पड़ता है, और भारी लोड के तहत 5% की वृद्धि हुई है, इस तथ्य के कारण कि ईएसएक्सआई "वास्तविक" धागे और "नकली" धागे के बीच अंतर जानने के लिए पर्याप्त स्मार्ट है। ( इसके अलावा भी बहुत कुछ है, लेकिन यह सामान्य शब्दों में है)। SQL सर्वर 2005 काफी स्मार्ट नहीं है, लेकिन यह एक अप-टू-डेट ऑपरेटिंग सिस्टम के साथ संयुक्त है जो HT को अक्षम करने के लिए थोड़ा लाभ होना चाहिए।

सभी ने कहा, मैं रोनाल्ड से सहमत हूं कि यह आपके एल 2 कैश होने की सबसे अधिक संभावना है। कैश आकार में 33% की गिरावट पर्याप्त है, और जब हम अपने एसक्यूएल सर्वर की कल्पना करते हैं तो हम हमेशा हर बार कच्ची घड़ी की गति पर कैश के लिए जाते हैं।


क्या आप बाहरी रूप से आत्मीयता सेट कर सकते हैं ताकि एसक्यूएल द्वारा सही 4 कोर को अनदेखा किया जा सके?
सैम केसर

3
आम तौर पर आप एक-दूसरे सीपीयू थ्रेड को आत्मीयता निर्धारित करते हैं, लेकिन जब तक MAXDOP सही ढंग से सेट हो जाता है, तब तक मुझे आत्मीयता स्थापित करने का कोई कारण नहीं दिखता। HT के साथ हालांकि पहला धागा CPU पर हिट करने के लिए "मुख्य" धागा बन जाता है, और दूसरा धागा "HT" धागा है। हालांकि कोई वास्तविक "मुख्य" और "ht" थ्रेड्स नहीं हैं, क्योंकि यह जो भी पहले वहां है, और फिर जब वे कार्य स्विच करते हैं, तो आदेश उलट जाता है।
मार्क हेंडरसन

Nehalem- आधारित CPU में बहुत, बहुत कम L2 कैश होते हैं, जिनमें से अधिकांश L3 साझा करते हैं।
Mircea Chirea

7

मेरे अनुभव के आधार पर, एचटी बना रहा था I / O ऑपरेशंस हमेशा के लिए मेरे सक्रिय नोड्स पर एक विंडोज 2008 R2 क्लस्टर (SQL Server 2008 R2 चल रहा है) पर ले रहा था। एक दिलचस्प तथ्य यह था कि यह न तो प्रतीक्षा आंकड़ों में परिलक्षित होता था और न ही मैं Microsoft समर्थन के लिए चलाए गए pssdiag में था।

जिस तरह से मैंने कम ओ / ओ देखा, वह सिर्फ भौतिक डिस्क के लिए ओएस काउंटरों को देखकर था। जैसा कि सैम ने बताया, मैंने इसके बारे में यहां और यहां लिखा है

अगर आपको I / O समस्या का अनुभव नहीं है और CPU बाध्य है, तो मैं आपको इस तरह से शुरू करने का सुझाव देता हूं:

पिनपॉइंट जो प्रक्रियाएं और टी-एसक्यूएल ब्लॉक सबसे सीपीयू उपयोग का कारण बन रहे हैं। हमारे अनुभव में, हमने I / O (HT को बंद करके) के साथ समस्या को ठीक करने के बाद, हमने कोड की पहचान की जो 2008 R2 में बहुत अच्छा प्रदर्शन कर रहा था और 2005 में ठीक कर रहा था। मैंने इसके बारे में यहां लिखा था ।

उच्च भार के अधीन रहते हुए, एडम मैकनिक के sp_whoisactive को चलाएं। आप इसे यहाँ से डाउनलोड कर सकते हैं । हम एक बहुत ही खराब CPU योजना का उपयोग कर रहे थे क्योंकि वास्तव में खराब योजना के कारण तार्किक रीड्स (20 मिलियन प्रति क्वेरी) की अत्यधिक मात्रा के कारण। हमारी प्रक्रियाएँ विभाजन की गई तालिकाओं के साथ अर्ध-अर्ध जोड़ कर प्रदर्शन कर रही थीं।

मेरी अगली सिफारिश टी-एसक्यूएल कोड के एक सेट की पहचान करने के लिए प्रोफाइलर को चलाने की है जो सीपीयू और आई / ओ तार्किक रीड्स दोनों में उच्च हैं।

ऊपर दिए गए कदमों से हम आपत्तिजनक प्रक्रियाओं को सुलझाने में सक्षम थे और 85% निरंतर सीपीयू उपयोग से लगभग शून्य हो गए।

गुड लक और कृपया मुझे एक लाइन ड्रॉप करने के लिए स्वतंत्र महसूस करें यदि आप एक ठीक पाते हैं जैसा कि मैं अपने ब्लॉग में मामला जोड़ना चाहूंगा।

धन्यवाद

ऑस्कर


1
प्रोफाइलर के लिए +1, मुसीबत की जगह पहचाने जाने के बाद मुझे कई बार बचाया
मार्क हेंडरसन

+1 आपके सभी सुझावों के लिए धन्यवाद, हमारे एसक्यूएल को एक उचित स्तर पर ले जाना एक कुल दुःस्वप्न है, हम टैग्स के साथ हमारे व्यवहार के लिए काफी हद तक पूर्ण रूप से निर्भर हैं, अक्सर हम विशेष टैग में वस्तुओं की एक सूची की तलाश कर रहे हैं ताकि हम पूरी पकड़ सकें इसे सेट और फ़िल्टर करें। उदाहरण के लिए, तारीखों के अनुसार टैग [x] और [y] के साथ प्रश्नों की एक सूची प्राप्त करने में फुलटेक्स्ट से बड़े पैमाने पर डेटा खींचना और फिर एक बड़े पैमाने पर शामिल होना शामिल है।
सैम केसर

समझ लिया। एक नमूना ले लो और इसे आँकड़ों के साथ चलाओ IO ON और देखो कि क्या आप सबसे तार्किक रीड्स के साथ किसी भी तालिका को इंगित कर सकते हैं। फिर, हम 2005 में ठीक काम कर रहे थे और 2008 R2 में वास्तव में खराब थे। यदि आप उच्च सीपीयू उपयोग पाते हैं और एक उच्च CXPACKET प्रतीक्षा करते हैं, तो 10 से 15 या 20 तक समानता के लिए लागत सीमा को बढ़ाकर पहले प्रयास करें।
ओजामोरा

अगर और कुछ नहीं मदद करता है, तो डीबी को ऑफ़लाइन करें, एचटी को बंद करें, और वहां से जाएं। सौभाग्य
ओजामोरा

sp_whoisactive एक बहुत बढ़िया उपकरण है, जिस तरह से क्लिक करने योग्य प्रश्न हैं, उससे प्यार करें
सैम केसर

2

चाहे एचटी अच्छा हो या बुरा उसे पिन करना मुश्किल है।

यह वास्तव में अनुभव और पढ़ने के आधार पर सर्वर लोड पैटर्न पर निर्भर करता है। यही है, जब यह प्रदर्शन को प्रभावित करता है तो यह इतनी बुरी तरह से करता है : अन्यथा आप इसे नोटिस नहीं करते हैं।

मैंने पढ़ा था कि थ्रेड्स कैश साझा करते हैं, जिसका अर्थ है कि प्रतिकूल परिस्थितियों में प्रत्येक थ्रेड दूसरे थ्रेड के कैश को अधिलेखित कर सकता है। यदि आपके पास बहुत अधिक समानता नहीं है, या आपका लोड कई छोटे प्रश्न हैं, तो यह आपको प्रभावित नहीं कर सकता है।

मैंने MAXDOP और प्रोसेसर आत्मीयता (एसक्यूएल सर्वर 2000 पर अपनी अंतिम वास्तविक डीबीए भूमिका में) के साथ कोशिश की है, लेकिन कभी भी कुछ भी निर्णायक नहीं मिल सका: लेकिन उस समय केवल मेरी दुकान के लिए।

एक त्वरित परीक्षण के रूप में, आप केवल भौतिक कोर (कम संख्या) का उपयोग करने के लिए प्रोसेसर आत्मीयता निर्धारित कर सकते हैं और देखें कि क्या होता है।

हालांकि, अधिकांश में आप अपने आधे कोर खो देते हैं। आजकल कि मैं कुछ साल पहले खेल रहा था की तुलना में कोई फर्क नहीं पड़ता जब यह 2 बनाम 4 या 4 बनाम 8 था। अब यह 8 बनाम 16 या 16 बनाम 32 है।

संपादित करें: स्लाव ओक्स द्वारा एक परीक्षण


कोर 0-3 शारीरिक और 4-7 तार्किक हैं? क्या यह ऐसे ही कार्य करता है? हम बता नहीं सकते थे, और मैं किसी भी उपकरण का पता नहीं लगा सकता था कि मुझे बताएं ..
जेफ एटवुड

2
@ जेफ एटवुड: मुझे बाद में और मिलेगा। मैं है यह कहीं पढ़ा .... अभी के लिए: support.microsoft.com/kb/322385
GBN

यह केबी लेख बहुत ज्यादा यह रकम है।
पोस्का

यद्यपि केबी लेख में कुछ उपयोगी जानकारी है, लेकिन यह सीधे जेफ के सवाल का जवाब नहीं देता है कि तार्किक प्रोसेसर भौतिक लोगों के लिए कैसे मैप किए जाते हैं। मेरा मस्तिष्क लगभग आधे रास्ते से गुजर रहा है, लेकिन उम्मीद है कि इस INTEL लेख से आपको यह पता लगाना चाहिए कि आपको मैपिंग का पता लगाने के लिए क्या चाहिए: software.intel.com/en-us/articles/… यह भी देखें software.intel.com/en-us/ ब्लॉग / 2009/12/21 /… अपने संबद्ध लिंक के साथ।
ब्रैड

@ जेफ एटवुड, @ ब्रैडसी: लॉर्डी, खोजने में कठिन। इसे देखें: यह इंटेल के पुनर्संयोजन पर निर्भर करता है। SQL सर्वर अंतर्निहित विंडोज़ एन्यूमरेशन download.microsoft.com/download/5/7/7/… का उपयोग करेगा ।
gbn

2

दुर्भाग्य से, मुझे नहीं लगता कि आपको "हाइपरथ्रेडिंग को बंद करने की कोशिश करें और देखें कि क्या वह मदद करता है" की तुलना में कोई और अधिक निश्चित उत्तर प्राप्त करने जा रहा है।

मेरे मूल धागे में जोनाथन के उपयोगी उत्तर के बावजूद (जिसे आपने अपने प्रश्न में जोड़ा था), मैं उस विशिष्ट सर्वर पर एचटी के प्रभाव के बारे में कोई निश्चित प्रमाण प्राप्त करने में सक्षम नहीं था, जिसकी मैं जांच कर रहा था। मेरे मामले में, सर्वर को प्रतिस्थापन के लिए पहले से ही निर्धारित किया गया था, इसलिए हम बस उन प्रतिस्थापन को "समस्या का ध्यान रखें" इसलिए बोलने के लिए दें।

मेरी सलाह:

1 के समानांतर-निर्धारण सेटिंग का एक सर्वर-स्तर अधिकतम डिग्री आज़माएं । SQL पर समानता सबसे अधिक है वैसे भी बड़े, लंबे समय तक चलने वाले प्रश्नों के लिए उपयोगी है, और आपके लोड (मेरा मानना ​​है) में वैसे भी बड़े पैमाने पर छोटे प्रश्नों की संख्या अधिक है। यह पूरी तरह से CXPACKET प्रतीक्षा को समाप्त करना चाहिए। यह कुछ व्यक्तिगत प्रश्नों को थोड़ा लंबा चला सकता है, लेकिन सर्वर पर कुल प्रश्नों के अधिक "थ्रूपुट" की अनुमति देनी चाहिए।

मेरे पास OLTP सर्वरों पर ऐसा करने के अच्छे परिणाम हैं। अन्य प्रकार के सर्वर (रिपोर्टिंग सर्वर, प्रोसेसिंग सर्वर, डेटा वेयरहाउसिंग) को निश्चित रूप से MAXDOP को उच्चतर सेट करने की आवश्यकता होती है।

और बस स्पष्ट होने के लिए, यह सेटिंग अभी भी SQL को एक JOIN में प्रत्येक व्यक्ति तालिका के लिए कई थ्रेड्स का उपयोग करने की अनुमति देगा, इसलिए आप वास्तव में समानता को पूरी तरह से समाप्त नहीं कर रहे हैं।

कम से कम एक कोशिश के लायक है, क्योंकि यह सेटिंग परिवर्तन तुरंत प्रभावी होता है और आपको SQL सेवा को पुनरारंभ करने की भी आवश्यकता नहीं होती है: http://msdn.microsoft.com/en-us/library/ms181007.aspx
इसका मतलब है कि आप स्विच कर सकते हैं यह तुरंत वापस आ गया अगर चीजें नरक में जाने लगीं।

BIOS में हाइपरथ्रेडिंग को बंद करने के लिए एक पूर्ण सर्वर रिबूट की आवश्यकता होगी, इसलिए थोड़ा अधिक जोखिम भरा है।


0

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

https://serverfault.com/a/196329/6390

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.