हमारे कॉर्पोरेट ईआरपी (डायनेमिक्स एएक्स 2012) को चलाने पर, मैंने देखा कि हमारे उत्पादन वातावरण हमारे विकास प्रणालियों की तुलना में बहुत धीमा लग रहा था।
ट्रेस चलाते समय विकास और उत्पादन वातावरण दोनों में समान गतिविधियां करने के बाद, मैंने पुष्टि की कि SQL क्वेरी हमारे उत्पादन वातावरण पर विकास की तुलना में बहुत धीरे-धीरे निष्पादित कर रही थी (औसतन 10-50x धीमी)।
सबसे पहले मैंने इसे लोड करने के लिए जिम्मेदार ठहराया, और उत्पादन वातावरण पर उसी गतिविधियों को बंद घंटों के दौरान फिर से चलाया और ट्रेस में समान परिणाम पाए।
मैंने SQL सर्वर में अपने प्रतीक्षा आँकड़े साफ़ कर दिए, फिर सर्वर को थोड़ी देर के लिए अपने सामान्य उत्पादन लोड के तहत चलने दिया, और फिर इस क्वेरी को चलाया:
WITH [Waits] AS
(SELECT
[wait_type],
[wait_time_ms] / 1000.0 AS [WaitS],
([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
[signal_wait_time_ms] / 1000.0 AS [SignalS],
[waiting_tasks_count] AS [WaitCount],
100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
FROM sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'CLR_SEMAPHORE', N'LAZYWRITER_SLEEP',
N'RESOURCE_QUEUE', N'SQLTRACE_BUFFER_FLUSH',
N'SLEEP_TASK', N'SLEEP_SYSTEMTASK',
N'WAITFOR', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT', N'XE_DISPATCHER_JOIN',
N'LOGMGR_QUEUE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT', N'DISPATCHER_QUEUE_SEMAPHORE',
N'TRACEWRITE', N'XE_DISPATCHER_WAIT',
N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
N'FT_IFTSHC_MUTEX', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'DIRTY_PAGE_POLL', N'SP_SERVER_DIAGNOSTICS_SLEEP')
)
SELECT
[W1].[wait_type] AS [WaitType],
CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
[W1].[WaitCount] AS [WaitCount],
CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
[W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage thresholdमेरे परिणाम इस प्रकार हैं:
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S
SOS_SCHEDULER_YIELD 4162.52 3.64 4158.88 4450085 77.33 0.0009 0.0000 0.0009
ASYNC_NETWORK_IO 457.98 331.59 126.39 351113 8.51 0.0013 0.0009 0.0004
PAGELATCH_EX 252.94 5.14 247.80 796348 4.70 0.0003 0.0000 0.0003
WRITELOG 166.01 48.01 118.00 302209 3.08 0.0005 0.0002 0.0004
LCK_M_U 145.47 145.45 0.02 123 2.70 1.1827 1.1825 0.0002ऐसा प्रतीत होता है कि अब तक का सबसे बड़ा इंतजार SOS_Scheduler_Yield है, और मैंने चारों ओर गुगली की और पाया कि यह आमतौर पर सीपीयू से संबंधित है, जो कि रखने में सक्षम नहीं है।
मैंने तब इस क्वेरी को उत्तराधिकार में कई बार चलाया।
SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255मुझे पता है कि मुझे गैर-शून्य runnable_tasks_count या लंबित_disk_io_count के साथ शेड्यूलर की तलाश है, लेकिन यह मूल रूप से लगभग हर समय शून्य है।
मुझे यह भी उल्लेख करना चाहिए कि समानांतरवाद की मैक्स डिग्री 1 पर सेट की गई थी, क्योंकि डायनेमिक्स एएक्स वर्कलोड आम तौर पर प्रकृति में ओएलटीपी है, और इसे बदलने से 8 ऊपर के प्रतीक्षा आंकड़ों में बहुत अंतर नहीं हुआ, वे लगभग उसी के साथ सटीक हो गए प्रदर्शन की समस्याएं।
मैं यहाँ से जाने के नुकसान की तरह हूँ, मेरे पास मूल रूप से एक सीपीयू सर्वर है जो प्रतीत होता है कि सीपीयू स्ट्रैप्ड है, लेकिन रननेबल_टैक्स या आईओ पर प्रतीक्षा नहीं कर रहा है।
मुझे पता है कि इस SQL सर्वर का IO सबसिस्टम बहुत अच्छा नहीं है, क्योंकि वास्तविक डेटाबेस वाले ड्राइव पर SQLIO चलाने से बहुत कम संख्याएँ हो सकती हैं (सोचें 10MB कुछ प्रकार के रीड / राइट के लिए सेकंड), उन्होंने कहा, ऐसा प्रतीत नहीं होता है कि SQL उस पर प्रतीक्षा कर रहा है क्योंकि सर्वर पर अधिकांश डेटाबेस को मेमोरी की मात्रा के कारण।
यहाँ मदद करने के लिए कुछ पर्यावरण जानकारी है:
उत्पादन वातावरण:
- एस क्यू एल सर्वर
- HP ProLian DL360p Gen8
- Intel Xeon E5-2650 0 @ 2.00GHz x 2 हाइपरथ्रेडिंग के साथ (32 तार्किक कोर)
- 184GB मेमोरी
- विंडोज सर्वर 2012
- SQL सर्वर 2012 मानक (RTM, अप्रकाशित) के 2 उदाहरण
- RAID 1 279GB ड्राइव (15k) C: ड्राइव में डेटाबेस और ऑपरेटिंग सिस्टम शामिल हैं
- अलग, अलग ड्राइव (ठोस स्थिति) पर पेज फ़ाइल और टेंपडीबी
मेरा DEV:
- हाइपर- V होस्टेड SQL सर्वर और Dynamics AX 2012 AOS सर्वर
- हाइपरथ्रेडिंग के साथ कोर i7 3.4ghz (8 तार्किक कोर)
- 8GB मेमोरी
- विंडोज सर्वर 2008 R2
- पूरे वीएम के लिए एसएसडी।
मैं अन्य चीजों पर किसी भी इनपुट का स्वागत करूंगा।