प्रदर्शन के लिए संघर्ष या सीपीयू समय किसने लिया

यह सब टंबलर के साथ शुरू हुआ। यह क्या है और इसकी आवश्यकता क्यों थी, इसके बारे में यहाँ वर्णित है: http://habrahabr.ru/company/oktell/blog/10/2626/ । अर्थात्, हमारे पास चार काम करने वाले कॉल सेंटर सर्वर थे, समान रूप से कॉन्फ़िगर किए गए और बाहरी और आंतरिक लाइनों के लगभग समान कॉन्फ़िगरेशन के साथ, उपयोगकर्ता और आंतरिक डेटाबेस की स्थापना। दूरसंचार ऑपरेटर को प्रत्येक सर्वर पर एक समान रिंग लोड प्राप्त हुआ, लेकिन सर्वरों ने इस पर अलग तरह से प्रतिक्रिया की!



एन सर्वर कॉन्फ़िगरेशन और ऑपरेटिंग सिस्टम

1 T1300 @ 1.66 1 जीबी रैम, विंडोज 2003 स्टैंडर्ड एड। आर 2 SP1 32 बिट

2 Intel Core Duo E8400 @ 3000 4 GB RAM, Windows 2003 Standard Ed.SP1 32 बिट

3 इंटेल पेंटियम 4 3 जीएचजेड 2 जीबी रैम, विंडोज 2003 स्टैंडर्ड एड। SP2 32 बिट

4 ई 3400 @ 2.60 2 जीबी रैम, विंडोज 2003 स्टैंडर्ड एड। R2 SP2 32 बिट



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



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









लक्ष्य इस सवाल का जवाब पाने के लिए था कि जब अन्य सभी सेवाओं पर कोई भार नहीं है, तो मुख्य व्यस्त क्या है। प्रोसेस एक्सप्लोरर - माइक्रोसॉफ्ट की एक मानक उपयोगिता - ने सुझाव दिया कि संसाधनों का मुख्य उपभोक्ता "हार्डवेयर व्यवधान" है। ऐसी खपत के कारणों का और अधिक विश्लेषण करने के लिए, एक और मानक Microsoft उपयोगिता, कर्न्रेट व्यू, डाउनलोड किया गया था। जैसा कि उपयोग के लिए सिफारिशों में वर्णित है, कमांड लाइन ने "C: \ Program Files \ KrView \ Kernrates \ Kernrate_i386_XP.exe >> log.txt" को निष्पादित किया और, कुछ समय बाद, Ctrl-C को दबाकर, इसे बंद कर दिया। फ़ॉर्म की जानकारी रखने वाली एक log.txt फ़ाइल प्राप्त करें:



/ ==================================

\ _ ================================

दिनांक: 2010/12/08 समय: 1:09:14

मशीन का नाम: RESERVCC

प्रोसेसरों की संख्या: 1

PROCESSOR_ARCHITECTURE: x86

PROCESSOR_LEVEL: 6

PROCESSOR_REVISION: 0e08

भौतिक मेमोरी: 1015 एमबी

पेजफाइल कुल: 2450 एमबी

आभासी कुल: 2047 एमबी

PageFile1: \ ?? \ C: \ pagefile.sys, 1524MB

OS संस्करण: 5.2 बिल्ड 3790 सर्विस-पैक: 1.0

WinDir: C: \ WINDOWS



कर्न्रेट उपयोगकर्ता-निर्दिष्ट कमांड लाइन:

Kernrate_i386_XP.exe



कर्नेल प्रोफ़ाइल (PID = 0): स्रोत = समय,

25000 ईवेंट्स / हिट की कर्नेट डिफ़ॉल्ट दर का उपयोग करना



------------ कुल मिलाकर सारांश: --------------



P0 K 0: 00: 36.671 (28.5%) U 0: 00: 09.671 (7.5%) I 0: 01: 22.343 (64.0%) DPC 0: 00: 29.484 (22.9%) व्यवधान 0: 00: 00.281 (0.2%) )

इंटरप्ट = 136809, इंटरप्ट रेट = 1063 / सेकंड।



कुल प्रोफ़ाइल समय = 128687 मिसे



बाइटस्टार्ट बाइट्सटॉप बाइट्सडिफ़।

उपलब्ध भौतिक मेमोरी, 443772928, 407339008, -36433920

उपलब्ध पेजफाइल (एस), 2104172544, 2093707264, -10465280

उपलब्ध आभासी, 2132660224, 2131611648, -1048576

उपलब्ध वर्चुअल, 0, 0, 0 विस्तारित



कुल औसत। दर

संदर्भ स्विच, 609407, 4736 / सेकंड।

सिस्टम कॉल, 5078088, 39461 / सेकंड।

पृष्ठ दोष, 119817, 931 / सेकंड।

I / O रीड ऑपरेशंस, 11671, 91 / सेकंड।

आई / ओ राइटिंग ऑपरेशंस, 209479, 1628 / सेकंड।

आई / ओ अन्य संचालन, 229216, 1781 / सेकंड।

आई / ओ रीड बाइट्स, 39981700, 3426 / आई / ओ

आई / ओ राइट बाइट्स, 19240135, 92 / आई / ओ

आई / ओ अन्य बाइट्स, 7130204725, 31107 / आई / ओ



- कर्नेल मोड के लिए परिणाम:

- OutputResults: कर्नेलमॉड्यूलकाउंट = 99

निम्न तालिका में प्रतिशत कर्नेल के लिए कुल हिट पर आधारित है



समय ४४६५१ हिट, प्रति हिट २५००० घटनाएँ - मॉड्यूल हिट्स% कुल घटनाएँ / सेक

इंटेलप्पम 27457 128685 61% 5334149

हाल 12284 128685 27% 2386447

ntkrnlpa 2868 128685 6% 557174

win32k 525 128685 1% 101993

alder9xp 427 128685 0% 82954

टीसीपी 254 128 685 0% 49345

Ntfs 251 128,685 0% 48762

एफडी 120 128 685 0% 23312

RDPDD 109 128 685 0% 21 175

e1e5132 109 128685 0% 21175

iaStor 97 128 685 0% 18844

एनडीआईएस 39 128 685 0% 7576

RDPWD 31 128 685 0% 6022

fltMgr 26 128 685 0% 5051

अमन १२ 128 १२ 128५ ०% २३३१

10dd 128 128 685 0% 1942

CLASSPNP 10 128 685 0% 1942

ftdisk 7 128 685 0% 1359

ipsec 3 128 685 0% 582

एनपीएफएस 2 128 685 0% 388

USBPORT 2 128 685 0% 388

volsnap 2 128 685 0% 388

TDTCP 1 128 685 0% 194

rdbss 1 128 685 0% 194

ws2ifsl 1 128 685 0% 194

netbt 1 128 685 0% 194

प्रहरी 1 128 685 0% 194

PartMgr 1 128 685 0% 194



==================================== RUN का अंत ================= ====================



इसके बाद, हम निर्धारित करते हैं कि कौन सा ड्राइवर "हार्डवेयर इंटरप्ट" प्रक्रिया को लोड करता है। यह कर्नटेट व्यू लॉग सूची में सबसे ऊपर होगा, और इसकी कोर ऑक्यूपेंसी का प्रतिशत प्रतिशत के बगल में दिखाया जाएगा। यह ध्यान देने योग्य है कि प्रतिशत सिस्टम लोड का कुल प्रतिशत नहीं दिखाते हैं, लेकिन ड्राइवरों द्वारा सर्वर कोर पर लोड का प्रतिशत।

हमने निर्धारित किया कि यह ड्राइवर Intelppm (इंटेल प्रोसेसर पावर मैनेजर) है। अगला - google हमारी मदद करने के लिए। इंटरनेट बड़ा, शक्तिशाली और असीमित है। उन्होंने जल्दी से महसूस किया कि इंटेलप्पम के साथ एक समस्या होती है, ऐसा अक्सर नहीं होता है, हालांकि, हम एकमात्र ऐसे व्यक्ति नहीं थे जिन्होंने इस तरह की आपदा का सामना किया। परिणाम खोजने के लिए धीमा नहीं था, एक लेख था जो न केवल समस्या का वर्णन करता है, बल्कि इसे हल करने का तरीका भी बताता है (मूल लेख का स्थायी पता यहां: http://www.osp.ru/text/print/302/5818429.html )

इसके अलावा, स्टीफन डौबर्टी की सिफारिशों के बाद, हम समझते हैं कि इंटेलपीएम एक प्रोसेसर पॉवर मैनेजमेंट ड्राइवर है, जिसे ऐसे सर्वर की जरूरत नहीं है, जहां बैटरी पॉवर का उपयोग नहीं किया जाता है। कई समाधान प्रस्तावित किए गए थे: दोषपूर्ण ड्राइवर को फिर से स्थापित करना, अपडेट करना या रोकना। आप क्या विकल्प चुनते हैं - अपने लिए देखें, Doherty की मूल सिफारिशों का पालन करना यहां तार्किक है।

हम रजिस्ट्री में चढ़ गए। इंटेल प्रोसेसर ड्राइवर डेटा रजिस्ट्री कुंजी HKEY_LOCAL_MACHINE / SYSTEM / करंट कंट्रोल सेट / सर्विसेज / इंटेलपीएमएम में स्थित है। Intelppm ड्राइवर को अक्षम करने के लिए, प्रारंभ पैरामीटर का मान 1 से 4 में बदल दिया गया था। Microsoft विशेषज्ञ, रजिस्ट्री की एक बैकअप प्रति बनाने की सलाह देते हैं, लेकिन हम रूसी लोग हैं, और 1 से 4 में एक पैरामीटर को बदलने के लिए क्या आवश्यक है।



रिस्टार्ट ने यह सुनिश्चित करने में मदद की कि प्रोसेसर लोड एक पूर्ण ((!) सर्वर लोड कॉल-सेंटर कॉल के साथ भी 60-70% की सीमा में है।

उसी समय, डिवाइस प्रबंधक बहुत दिलचस्प दिखता है:



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