उपयोगकर्ता की शिकायत "1C हैंग हो जाता है", जिसके बारे में आईटी विशेषज्ञ अच्छी तरह से जानते हैं, इसके कई कारण हैं। एक सही "निदान" करने के लिए - किसी समस्या की पहचान करना और उसका विश्लेषण करना, इसके पुनरुत्पादन की आवश्यकता होती है, क्योंकि एक समस्या जिसे पुन: प्रस्तुत नहीं किया जा सकता है, एक नियम के रूप में, हल करना लगभग असंभव है। 1C फ़्रीज़िंग के लक्षणों को समझने के बाद, हम एक कुशलतापूर्वक कार्य प्रणाली की ओर पहला कदम उठाएंगे।

बहुत लंबा सिस्टम स्टार्टअप

लंबा स्टार्टअपकंप्यूटर पर डेटाबेस की सूची में सूचना सुरक्षा जोड़ने के बाद पहली बार एक उपयोगकर्ता के अंतर्गत भारी कॉन्फ़िगरेशन एक सामान्य घटना है। पहले लॉन्च के दौरान, कॉन्फ़िगरेशन कैश किया गया है। दूसरा और बाद का रन तेज़ होना चाहिए।

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

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

ऐसी संभावना है कि कॉन्फ़िगरेशन प्रारंभ होने पर इंटरनेट से डेटा पढ़ने का प्रयास कर रहा है। इससे सिस्टम स्टार्टअप समय भी बढ़ जाता है।

फॉर्म खुलने में काफी समय लग रहा है

फॉर्म लंबे समय तक खुलने के कारण हो सकते हैं:

1. प्रपत्र पर बड़ी संख्या में नियंत्रण - प्रपत्र बनाने और प्रपत्र तत्वों की व्यवस्था को आपस में जोड़ने में समय व्यतीत होता है;
2. फॉर्म आरंभीकरण के दौरान एल्गोरिदम का निष्पादन। यह संभव है कि जब फॉर्म बनाया जाता है, तो कुछ शर्तों की जाँच की जाती है और/या संबंधित ऑब्जेक्ट को डेटाबेस से पढ़ा जाता है।

फॉर्म को सरल बनाकर पहली समस्या का "निवारण" किया गया है। उदाहरण के लिए, कुछ नियंत्रणों को अलग-अलग रूपों में रखा जा सकता है, जो उपयोगकर्ता के लिए और भी सुविधाजनक हो सकता है। उदाहरण के लिए, यदि फॉर्म में पता फ़ील्ड "शहर", "सड़क", "घर" आदि है, तो पते को एक अलग फॉर्म में संपादित करना बेहतर है।

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

एक इंटरैक्टिव क्रिया के रूप में, उपयोगकर्ता द्वारा प्रपत्र तत्व पर एक मान का चयन करने का प्रयास करने पर विचार करें। इसके जवाब में, सिस्टम "कुछ के बारे में सोचता है।" ऐसा निम्नलिखित कारणों से हो सकता है:

1. इस क्रिया में चलने वाले एल्गोरिदम मूल्य चयन मोड को प्रभावित करने वाले संबंधित डेटा की जांच या गणना करते हैं;
2. इस मान को चुनने के लिए खुलने वाला चयन फ़ॉर्म प्रारंभ होने पर डेटाबेस से सभी ऑब्जेक्ट को पढ़ता है।

पहली समस्या को हल करने के लिए, आपको "प्रदर्शन मापन" का उपयोग करना चाहिए, संसाधन-गहन एल्गोरिदम ढूंढना चाहिए और उन्हें अनुकूलित करना चाहिए।

दूसरी समस्या को अक्सर चॉइस फॉर्म के कार्यान्वयन का विश्लेषण करके हल किया जा सकता है। उदाहरण के लिए, आपको यह सुनिश्चित करना चाहिए कि "डायनामिक डेटा रीडिंग" प्रॉपर्टी एक डायनेमिक सूची के लिए सेट है, कि "मेन टेबल" प्रॉपर्टी सही ढंग से सेट है, और सूची कार्यान्वयन स्पष्ट रूप से संसाधन-गहन एल्गोरिदम का उपयोग नहीं करता है।

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

अद्यतनों पर बहुत लंबी प्रतिक्रिया

हालाँकि, मामूली लक्षणों में से एक, कुछ सिस्टम समस्याओं के बारे में बता सकता है: बैकअप शुरू करते समय 1C अपडेट रुक जाता है। यह मुख्य रूप से इंटरनेट के माध्यम से अपडेट करते समय होता है और, सबसे अधिक संभावना है, यह इंगित करता है कि कॉन्फ़िगरेशन को लंबे समय तक अपडेट नहीं किया गया है और रिलीज़, एक के बाद एक जारी होने के कारण फ़्रीज़ हो गया है। आप समय पर अपडेट इंस्टॉल करके ऐसी समस्या को रोक सकते हैं, और यदि आपको इसका सामना करना पड़ता है, तो आप बैकअप प्रक्रिया को आसानी से बाधित कर सकते हैं। कॉन्फिगरेटर शुरू करने के बाद, डेटाबेस सामान्य मोड में किए गए परिवर्तनों के साथ शुरू होगा।

यह ध्यान दिया जाना चाहिए कि 1C 8.3 अपडेट के दौरान अक्सर रुक जाता है क्योंकि इसके लिए अधिक संसाधन-गहन हार्डवेयर की आवश्यकता होती है पिछले संस्करणप्लेटफार्म. यह रैम की मात्रा पर ध्यान देने योग्य है और, यदि आवश्यक हो, तो इसे बढ़ाएं - यह, सिद्धांत रूप में, समस्या को हल करने में मदद करनी चाहिए "कॉन्फ़िगरेशन अपडेट करते समय 1C फ़्रीज हो जाता है।"

वस्तुओं को रिकॉर्ड करने/दस्तावेजों को निष्पादित करने की लंबी प्रक्रिया

इस मामले में, "फोटोग्राफी पर आधारित उपचार" को व्यावहारिक रूप से बाहर रखा गया है, क्योंकि कारण बहुत विविध हो सकते हैं, ऑब्जेक्ट में बड़ी मात्रा में डेटा से लेकर ताले की प्रतीक्षा तक।

लेकिन इस मामले में भी, विश्लेषण के लिए एक दिशा की रूपरेखा तैयार करना संभव है।

दिन के समय या उपयोगकर्ताओं की संख्या (एक मोटे, व्यक्तिपरक अनुमान के रूप में) के कारण रिकॉर्डिंग समय में महत्वपूर्ण परिवर्तनों की अनुपस्थिति कोड में या ऑब्जेक्ट के डेटा की मात्रा में एक समस्या का संकेत देती है। विश्लेषण के लिए, "प्रदर्शन माप" उपकरण का उपयोग करना समझ में आता है।

अस्पष्ट निर्भरताओं के साथ रिकॉर्डिंग समय में एक नाटकीय बदलाव के लिए समस्या की घटना का सांख्यिकीय विश्लेषण करने की आवश्यकता होती है, अर्थात। अदाकारी का समीक्षण। सबसे आसान तरीका लॉग बुक के उपयोग का विश्लेषण करना है। यहां एक अतिरिक्त लाभ यह है कि 1C:एंटरप्राइज़ 8 प्लेटफ़ॉर्म SQLite प्रारूप में फ़ाइल में लॉग डेटा को सहेजने का समर्थन करता है। यह आपको लॉग डेटा का विश्लेषण करने के लिए SQL क्वेरी का उपयोग करने की अनुमति देगा। लॉग डेटा से ऑब्जेक्ट लिखने का समय प्राप्त करना काफी संभव है, इस तथ्य को देखते हुए कि प्रत्येक ऑब्जेक्ट लेखन एक लेनदेन में किया जाता है, और प्रत्येक लेनदेन की अपनी पहचान संख्या होती है।

यदि सांख्यिकीय विश्लेषण के परिणाम से पता चला है कि किसी वस्तु का रिकॉर्डिंग समय दिन के समय पर निर्भर करता है, न कि उपयोगकर्ताओं की संख्या पर, तो 1C सर्वर और डेटाबेस सर्वर पर लोड का विश्लेषण करना आवश्यक है। यह संभव है कि सर्वर नियमित प्रक्रियाएं चला रहा हो जो अनावश्यक संसाधन ले रही हों।

यदि ऑब्जेक्ट लिखने में लगने वाला समय उपयोगकर्ताओं की संख्या पर निर्भर करता है, तो समस्या सबसे अधिक संभावना कोड (संभवतः लॉक पर प्रतीक्षा) या में है बैंडविड्थउपकरण। उन्हें हल करने के लिए, आपको "1सी: विशेषज्ञ" क्षमता वाले एक विशेषज्ञ को शामिल करना चाहिए तकनीकी मुद्दे", चूंकि ऐसी समस्या को हल करने के लिए कोई एकीकृत नियम नहीं हैं।

यदि किसी प्रोग्राम ने प्रत्युत्तर देना बंद कर दिया है, तो वह माउस या कीबोर्ड पर प्रतिसाद नहीं देता है, और शायद "प्रोग्राम प्रत्युत्तर नहीं दे रहा है" संदेश भी प्रकट होता है, इसे फ्रोजन प्रोग्राम कहा जाता है।

कभी-कभी ऐसा होता है कि एक फ्रोजन प्रोग्राम आपके काम में हस्तक्षेप नहीं करता है, लेकिन कभी-कभी, इसके विपरीत, एक फ्रोजन प्रोग्राम के कारण पूरे ओएस का काम धीमा हो सकता है, किसी भी स्थिति में, समस्या का समाधान होना चाहिए हो गया।

जो नहीं करना है:

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

2) रीसेट बटन दबाएं- यह बटन सिस्टम यूनिट के सामने स्थित होता है और रिबूट को मजबूर करने का काम करता है। इसे केवल सबसे निराशाजनक स्थितियों में ही दबाया जाना चाहिए, जब अन्य तरीके मदद नहीं करते हैं।

3) अनावश्यक हरकतें करना- यदि आपका प्रोग्राम जमे हुए प्रोग्राम के कारण धीमा होने लगता है ऑपरेटिंग सिस्टम, तो कोई भी अनावश्यक कार्रवाई स्थिति को और खराब कर देगी। अनावश्यक क्रियाओं से मेरा तात्पर्य किसी जमे हुए प्रोग्राम को पुनः आरंभ करने का प्रयास करना (किसी भी परिस्थिति में आपको ऐसा नहीं करना चाहिए), कोई अन्य प्रोग्राम लॉन्च करना, स्टार्ट मेनू या अन्य मेनू खोलना। यदि स्थिति विशेष रूप से गंभीर है, तो आपको केवल माउस को नहीं हिलाना चाहिए, क्योंकि कर्सर रुक सकता है और समस्या को हल करना अधिक कठिन होगा।

4) बहुत लंबे समय तक प्रतीक्षा करें- एक नियम के रूप में, यह समझने के लिए कि प्रोग्राम फ़्रीज़ हो गया है, पाँच मिनट प्रतीक्षा करना पर्याप्त है, यदि आपके पास कमज़ोर कंप्यूटर है, तो इसे 15-20 मिनट दें, इससे अधिक प्रतीक्षा करना आमतौर पर बेकार है।

5) घबरा जाना- सिस्टम यूनिट को लात मारने या कीबोर्ड को टेबल पर पटकने से मामले में कोई मदद नहीं मिलेगी। मैंने यह बिंदु विशेष रूप से लिखा है, क्योंकि अज्ञात कारणों से लोग कभी-कभी ऐसा करते हैं (शायद हमारे अतीत के कारण, जब एक ट्यूब टीवी काम नहीं करना चाहता था, तो वे आमतौर पर इसे अपने हाथ से मारते थे और इससे मदद मिलती थी)। कंप्यूटर एक ट्यूब टीवी नहीं है, इसलिए इसे मत मारो।

क्या करें

आपको प्रोग्राम को बंद करने का प्रयास करने की आवश्यकता है, यदि ऊपरी दाएं कोने में क्रॉस पर क्लिक करने और alt + f4 संयोजन से मदद नहीं मिलती है, तो आपको निम्न कार्य करने की आवश्यकता है:

कार्य प्रबंधक खोलने के लिए कुंजी संयोजन दबाएँ:

विंडोज़ एक्सपी के लिए "Ctrl + Alt + Del"।

विंडोज 7 के लिए "Ctrl + Shift + Esc"।

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

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

यदि फ्रोजन प्रोग्राम "एप्लिकेशन" टैब में प्रदर्शित नहीं होता है, तो आपको "प्रोसेस" टैब पर जाना होगा, फ्रोजन प्रोग्राम की प्रक्रिया ढूंढनी होगी और इसे समाप्त करना होगा। किसी प्रक्रिया को खोजने का सबसे आसान तरीका नाम से है; आप प्रोसेसर लोड की डिग्री के आधार पर भी खोज सकते हैं; आमतौर पर जमे हुए एप्लिकेशन का प्रतिशत बड़ा होता है।

1C:Enterprise 8 के प्रदर्शन पर अवरोधन का प्रभाव

गिलेव टीम कई वर्षों से प्रदर्शन के मुद्दों पर काम कर रही है और अन्य चीजों के अलावा, ताले और गतिरोध पर प्रतीक्षा को खत्म करने के मुद्दों को सफलतापूर्वक हल किया है।

नीचे हम इन समस्याओं को हल करने में अपने अनुभव का वर्णन करेंगे।

1सी में अवरोधन समस्याओं का पता लगाना

मल्टीप्लेयर मोड में प्रदर्शन संबंधी समस्याएं आवश्यक रूप से खराब कोड या खराब हार्डवेयर से संबंधित नहीं हैं। सबसे पहले, हमें इस प्रश्न का उत्तर देने की आवश्यकता है - कौन सी प्रदर्शन समस्याएं मौजूद हैं और उनके कारण क्या हैं?

सैकड़ों उपयोगकर्ताओं की गतिविधियों को मैन्युअल रूप से ट्रैक करना असंभव है; आपको एक ऐसे उपकरण की आवश्यकता है जो ऐसी जानकारी के संग्रह को स्वचालित करता हो।

कई उपकरण हैं, लेकिन उनमें से लगभग सभी में एक बहुत महत्वपूर्ण खामी है - कीमत।

लेकिन एक रास्ता है - हम चुनते हैं

हम MS SQL सर्वर पर समस्या की जांच करेंगे, इसलिए हमें इस सेट से निम्नलिखित सेवाओं की आवश्यकता होगी:

1. लंबे अनुरोधों की निगरानी और विश्लेषण(यहां स्थापना के बारे में और पढ़ें) - उप-क्षेत्र के लिए दीर्घकालिक संचालन की उपस्थिति का आकलन करने की आवश्यकता है।

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

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

3. 1सी और एमएस एसक्यूएल सर्वर में आपसी लॉक का विश्लेषण(यहां सेटअप के बारे में और पढ़ें) - हमें और अधिक मूल्यांकन करने की अनुमति देगा कठिन स्थितियांसंसाधनों की प्रतीक्षा के साथ, जब कई प्रतिभागी पहले से ही कुछ संसाधनों को अवरुद्ध करके "कब्जा" करने में कामयाब रहे हैं और अब इस तथ्य के कारण एक-दूसरे के लिए इंतजार करने के लिए मजबूर हैं कि वे कब्जे वाले संसाधनों को तब तक जारी नहीं कर सकते जब तक कि पड़ोसियों द्वारा अवरुद्ध अन्य संसाधनों पर कब्जा पूरा नहीं हो जाता।

सामान्य तौर पर, ऐसी कठिन परिस्थिति को मैन्युअल रूप से नहीं सुलझाया जा सकता, ऐसी सेवा की आवश्यकता होती है।

4. उपकरण भार का नियंत्रण(यहां सेटअप के बारे में और पढ़ें) हमें सवालों के जवाब देने में मदद करता है - सिस्टम में कितने उपयोगकर्ता हैं, क्या उनके पास लॉक हैं, कितने लॉक हैं, क्या हार्डवेयर लोड का सामना कर सकता है?

सेवाएँ स्थापित करना बहुत आसान है, लेकिन यदि आपके पास अभी भी प्रश्न हैं, तो वे हैं!

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

वास्तव में, हम सभी प्रदर्शन समस्याओं के बारे में जानकारी प्राप्त करते हैं और "सिस्टम में कितनी समस्याएं हैं", "वे वास्तव में कहां होती हैं", "प्रत्येक समस्या किस सटीक आवृत्ति के साथ होती है", "कौन सी समस्याएं हैं" जैसे प्रश्नों का सटीक उत्तर दे सकते हैं महत्वपूर्ण और जो गौण हैं”। वे। हम वे सभी पूर्वापेक्षाएँ देखते हैं जो समस्या का कारण बनीं।

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

परिणामस्वरूप, हमें प्रदर्शन की एक तस्वीर मिलती है जिसे मापा जाता है

- अनुरोध समय (बेशक, वजन के आधार पर समस्याग्रस्त अनुरोधों की रैंकिंग (इस अनुरोध पर कॉल की संख्या के आधार पर अनुरोध समय);

- ताले के लिए प्रतीक्षा समय;

इसलिए, हमने अवरोधों पर अपेक्षाओं का विश्लेषण सेवा लॉन्च की

शीर्ष तालिका में, सेवा "उम्मीदों के वजन" के कुल वजन को ध्यान में रखते हुए, अवरोधन के "पीड़ितों" की एक सूची दिखाती है।

निचली तालिका में, प्रत्येक पीड़ित के लिए "अत्यधिक प्रतिस्पर्धी संसाधन के लिए संघर्ष" में एक या अधिक प्रतिभागियों पर विचार किया जाता है, जहां अवरोधन प्रतीक्षा उत्पन्न हुई।

निचली तालिका में, "टाइमआउट" घटनाओं में से एक का विवरण खोलें। जैसे उदाहरण के लिए चित्र में।

"अपराधी" के साथ लाइन को हाइलाइट करके, हम देखेंगे कि बाधा _Reference64 तालिका थी, और "अज्ञात" क्षेत्र के साथ क्लस्टर्ड इंडेक्स पर एक समस्या उत्पन्न हुई। शायद भविष्य में हम इसका नाम बदलकर "टेबल" कर देंगे, क्योंकि वास्तव में यह व्यवहार अवरुद्ध क्षेत्र को बढ़ाने/बड़ा करने के लिए विशिष्ट है।

"पीड़ित" वाली पंक्ति से पता चलता है कि कौन सा कोड स्थिति का बंधक था और सब कुछ ब्लॉक नहीं कर सका, केवल "कुंजी द्वारा" लाइन (इस तालिका में न्यूनतम डेटा अवरुद्ध क्षेत्र)।

इस समस्या को "सही ढंग से" और "आसान" तरीके से हल किया जा सकता है।

द्वारा सही तरीकाऐसा करना अधिक कठिन है - वास्तव में, आपको ऐसी स्थितियों के घटित होने की संभावना को कम करते हुए, कोड को फिर से लिखना होगा।

कारकों में से एक, चाहे यह अजीब लग सकता है, अवधि में कमी है।

आप लेनदेन की अवधि कम कर सकते हैं:

1. एल्गोरिथम को फिर से लिखना

2. क्वेरी को दोबारा लिखना (तेज क्वेरी तालिकाओं पर जटिल लेनदेन में लॉक की संभावना को कम कर देती है, जो कभी-कभी क्वेरी में भी नहीं हो सकती है!)

2.1 लापता कवरिंग इंडेक्स को जोड़ना (कभी-कभी एक इंडेक्स न केवल क्वेरी को गति देता है, बल्कि डेटा रीडिंग क्षेत्र को भी कम कर देता है, जिससे अवरुद्ध होने की संभावना कम हो जाती है)

3. लेन-देन में संसाधित डेटा की मात्रा को कम करना (रैखिक गति के अलावा, हम लॉक एस्केलेशन के बारे में भी याद रखते हैं)

4. प्रत्येक प्रवाह के भीतर उपकरण उत्पादकता बढ़ाना

निष्पादन समय का अनुरोध करें

1) अलग-अलग उपयोगकर्ता अलग-अलग डेटा के साथ समानांतर में काम कर सकते हैं
2) विभिन्न उपयोगकर्ताओं को एक ही डेटा के साथ कड़ाई से क्रमिक रूप से काम करना चाहिए

हालाँकि, तालों के उपयोग को अनुकूलित करना संभव है, जिससे समग्र प्रतीक्षा समय कम हो जाएगा।

अवरोधन कैसे काम करता है (आपको यह पैराग्राफ पढ़ने की ज़रूरत नहीं है)

एक विशेष SQL सर्वर मॉड्यूल, लॉक मैनेजर, ताले को संभालता है। उनके कार्यों में शामिल हैं:

• ताले बनाना और स्थापित करना;
• ताला खोलना;
• अवरोधन का बढ़ना;
• लॉक संगतता का निर्धारण;
• गतिरोध दूर करना और भी बहुत कुछ।

जब कोई उपयोगकर्ता डेटा को अपडेट करने या पढ़ने का अनुरोध करता है, तो DBMS लेनदेन प्रबंधक यह निर्धारित करने के लिए DBMS लॉक मैनेजर को नियंत्रण भेजता है कि क्या अनुरोधित संसाधन लॉक किए गए हैं, और यदि हां, तो क्या अनुरोधित लॉक वर्तमान के साथ संगत है। यदि लॉक असंगत हैं, तो डेटा अनलॉक होने तक वर्तमान लेनदेन के निष्पादन में देरी होती है। एक बार डेटा उपलब्ध हो जाने पर, लॉक प्रबंधक अनुरोधित लॉक प्राप्त कर लेता है और लेनदेन प्रबंधक को नियंत्रण लौटा देता है।

प्रदर्शन को कम करने वाला मुख्य कारण अवरोधन है

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

आवश्यक और अनावश्यक ताले के बीच अंतर

जब कोई उपयोगकर्ता लॉक पर प्रतीक्षा करते समय किसी त्रुटि की रिपोर्ट करता है, तो उसके दृष्टिकोण से यह हमेशा एक त्रुटि होती है, क्योंकि उदाहरण के लिए यह उसके काम में हस्तक्षेप करता है - उसके काम को पूरा करने में लगने वाला समय बढ़ जाता है।

अनुभव एक सरल नियम सुझाता है: यदि अनुरोध निष्पादन समय का आधे से अधिक वास्तव में अवरुद्ध संसाधन की प्रतीक्षा कर रहा है, तो आपको यह देखने की ज़रूरत है: शायद आप कुछ लॉकिंग को अनुकूलित कर सकते हैं और संसाधन अवरुद्ध समय को कम कर सकते हैं।

यहाँ, मानो संयोग से, मैं एक परिभाषा प्रस्तुत करता हूँ:

ब्लॉक पर इंतज़ार कर रहा हूँ यह एक ऐसी स्थिति है जो तब घटित होती है जब दो उपयोगकर्ता एक ही समय में समान डेटा कैप्चर करने का प्रयास करते हैं। इस स्थिति में, इनमें से एक उपयोगकर्ता अवरुद्ध हो जाता है, अर्थात उसे पहले उपयोगकर्ता का लेनदेन पूरा होने तक प्रतीक्षा करनी होगी।

लेन-देन डेटा (अधिकांश) के साथ गणना और संचालन का एक सेट है ज्वलंत उदाहरण— किसी दस्तावेज़ को निष्पादित करते समय) एकल संपूर्ण के रूप में निष्पादित किया जाता है। किसी भी लेन-देन के संचालन में विफलता के परिणामस्वरूप पूरा लेन-देन रद्द हो जाता है।

इसलिए, बहु-उपयोगकर्ता इन्फोबेस में उपयोगकर्ता अक्सर शिकायत कर सकते हैं कि इन लॉक के कारण काम करना असंभव है, जबकि कोड में वास्तव में ऐसे लॉक हो सकते हैं जिनकी इस स्थान पर आवश्यकता नहीं है (अनावश्यक)।
और कॉन्फ़िगरेशन कोड में भी, वे स्वयं मौजूद नहीं हो सकते हैं; आप उनके बारे में पढ़ सकते हैं, उदाहरण के लिए, यहां http://kb.1c.ru/articleView.jsp?id=30 (लेख पुस्तक का एक अंश है) पी.एस. बेलौसोव, ए.वी.ओस्ट्रोवेरह द्वारा "1सी:एंटरप्राइज़: 8.0 से 8.1 तक।" मैं ताले के बीच के अंतर को समझाने का एक सरल तरीका प्रदान करता हूं सरल उदाहरणइसलिए:

1C:एंटरप्राइज़ मोड में अपने कॉन्फ़िगरेशन में, सामान की समान संरचना के साथ दो समान चालान बनाएं। लेकिन विभिन्न प्राप्त गोदामों को इंगित करना सुनिश्चित करें।
पोस्टिंग प्रोसेसिंग कोड में, आपको स्क्रीन पर प्रदर्शित संदेश के साथ एक पंक्ति जोड़ने की आवश्यकता है (या अन्य कोड जो पोस्टिंग प्रोसेसिंग के निष्पादन में 21 सेकंड की देरी कर सकता है (यदि पैरामीटर डिफ़ॉल्ट रूप से हैं तो ब्लॉकिंग टाइमआउट 20 सेकंड के बाद होता है)) .
दो दस्तावेज़ पोस्ट करें.
यदि कोई टाइमआउट होता है, और तार्किक रूप से माल विभिन्न गोदामों में पहुंचता है, तो एप्लिकेशन में अनावश्यक लॉक होते हैं। व्यावसायिक तर्क (सामान्य ज्ञान पर विचार करें) यहां कोई अवरोध नहीं होना चाहिए।
यदि हम अब इन दोनों इनवॉइस में समान गोदाम बनाते हैं। फिर एक साथ निष्पादन करने के प्रयास के परिणामस्वरूप उत्पन्न अवरोध उत्पन्न होगा आवश्यक लॉकिंगऔर यह अच्छा है!

वे। जबकि चालान गोदाम में शेष राशि में परिवर्तन करता है, दूसरे को इंतजार करना होगा।

निःसंदेह, यह सरल उदाहरण भी कई प्रश्न छोड़ जाता है। उदाहरण के लिए, क्या होगा यदि दस्तावेज़ एक आपूर्तिकर्ता से हैं और उस पर ऋण "चलता है"। और अगर यह सिर्फ गोदाम में शेष राशि नहीं है जो चल रही है, बल्कि कई रजिस्टर और विभिन्न प्रकार के दस्तावेज़ भी हैं।
लेकिन सबसे महत्वपूर्ण सवाल यह है कि किस व्यावसायिक तर्क के आधार पर रुकावटें नहीं आनी चाहिए। इस व्यावसायिक तर्क को कौन निर्धारित करता है और अवरोधन के संदर्भ में कहाँ? लेकिन आइए हर चीज़ के बारे में क्रम से बात करें।

अत्यधिक लॉक अनावश्यक लॉक होते हैं जिनकी डेटा अखंडता सुनिश्चित करने के दृष्टिकोण से आवश्यकता नहीं होती है और साथ ही सिस्टम के समग्र प्रदर्शन को कम करते हैं, जिससे कुल डाउनटाइम बढ़ जाता है - लॉक पर प्रतीक्षा करना।
आवश्यक लॉकिंग तब होती है जब दो उपयोगकर्ता समान संसाधन (डेटा ऑब्जेक्ट) प्राप्त करते हैं। यदि उपयोगकर्ता गैर-अतिव्यापी संसाधनों के साथ काम कर रहे हैं, लेकिन लॉक पर प्रतीक्षा कर रहे हैं, तो लॉक को अनावश्यक माना जाता है।

अतिरेक को लॉक करने के लिए सबसे समझने योग्य मानदंड हैं:

1. आपसी ताले;

2. अवरोधन का स्तर (क्षेत्र) आवश्यकता से अधिक है (जैसा कि) विशेष मामलाअवरोधन स्तर को बढ़ाना, तथाकथित। वृद्धि);

3. अवरुद्ध करने का समय अवरुद्ध करने वाली वस्तु के "वास्तविक" उपयोग के समय से अधिक लंबा है।

1सी:एंटरप्राइज़ मेटाडेटा के संदर्भ में समस्याओं के समूहीकरण के बारे में जानकारी प्राप्त करने के बाद, मैं सबसे पहले निम्नलिखित वस्तुओं पर ध्यान देने की सलाह देता हूं:

• स्थिरांक
• परिणाम को
• लेखांकन रजिस्टर
• संचय रजिस्टर
• सूचना रजिस्टर
• गणना रजिस्टर

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

यह आंकड़ा MS SQL सर्वर 2005 डेटाबेस तालिका में SCP कॉन्फ़िगरेशन स्थिरांक की भौतिक स्थिति को दर्शाता है।

इसका मतलब यह है कि एक स्थिरांक को लॉक करने से सभी स्थिरांक लॉक हो जाएंगे। DBMS तालिका की संपूर्ण एकल पंक्ति पर लॉक लगाता है, अर्थात। सभी स्थिरांकों के लिए.

हालाँकि, प्लेटफ़ॉर्म के नवीनतम रिलीज़ में, स्थिरांक का भंडारण बदल दिया गया है। अब प्रत्येक स्थिरांक एक अलग तालिका है। हालाँकि, बहुत अधिक बहकावे में न आएं, यदि आप हजारों टेबल बनाते हैं, तो आप मास्टर बेस पर लॉक प्राप्त कर सकते हैं।

ध्यान दें, यदि आपका कॉन्फ़िगरेशन लंबे समय से मौजूद है, तो आप कॉन्फ़िगरेशन का परीक्षण और सुधार करके स्टोरेज प्रारूप को "पुनर्गठन" करके बदल सकते हैं।

2) अनुक्रम मेटाडेटा ऑब्जेक्ट का उपयोग बंद करें। कम से कम आंदोलनों से जब परिचालन कार्यान्वयन, गैर-ऑपरेटिव (अतिरिक्त) प्रक्रियाओं के दौरान कार्यान्वित करें। देखें कि इसे कैसे लागू किया जाता है नवीनतम संस्करणयूपीपी.

3) यदि सिस्टम बहु-उपयोगकर्ता मोड में लेखांकन रजिस्टर में गतिविधियों की ऑनलाइन रिकॉर्डिंग करता है, तो यह अनुशंसित है:

• इस रजिस्टर के लिए कुल पृथक्करण मोड सक्षम करें;
• परिचालन कार्य के दौरान रजिस्टर बैलेंस नियंत्रण का उपयोग न करें।

4) संचय रजिस्टर में, ऐसे मामलों में जहां "ऑपरेटिव" डेटा प्राप्त करने की कोई आवश्यकता नहीं है, आप कुल के विभाजन को सक्षम कर सकते हैं, जिससे डेटा रिकॉर्डिंग की समानता बढ़ जाएगी और सामान्य रूप से काम में तेजी आएगी। मापों की सावधानीपूर्वक निगरानी करें ताकि माप में अधिकतम विवरण के साथ "अवशेष" प्राप्त किए जा सकें।

5) आप केवल प्लेटफ़ॉर्म द्वारा बनाए गए कुछ अनावश्यक लॉक से छुटकारा पा सकते हैं। कॉन्फ़िगरेशन के स्वचालित संचालन मोड में, प्लेटफ़ॉर्म अवरुद्ध संसाधनों को "कब्जा" कर लेता है। चिंता मुक्त कीमत स्वचालित मोड- इंडेक्स रेंज की सीमाओं पर ताले, खाली टेबल पर ताले और लॉक एस्केलेशन संभव है।

ये लॉक लेनदेन में डेटा से पूरी तरह गायब हो जाते हैं। यानी नियंत्रित मोड में काम करने पर यह इंटरलॉकिंग संभव नहीं होगी।

मैं पहले ही कई बार "प्रबंधित ताले" और "प्रबंधित मोड" कह चुका हूं। आपको यह समझने की आवश्यकता है कि ताले दो प्रकार के होते हैं:
क्वेरी निष्पादित करते समय DBMS लॉक स्वचालित रूप से DBMS स्तर पर स्थापित हो जाते हैं।
1सी: डेटा लिखते (संशोधित) करते समय एंटरप्राइज़ लॉक स्वचालित रूप से स्थापित होते हैं और डेटा पढ़ते समय हमेशा मैन्युअल रूप से स्थापित होते हैं।

एक सूक्ष्म पाठक कहेगा कि 1C भी ऑब्जेक्ट और नॉन-ऑब्जेक्ट लॉक में विभाजित होता है, लेकिन अब हम इस दृष्टिकोण को नहीं छूएंगे।

लेकिन मैं ध्यान देता हूं कि यह 1सी विशेषज्ञ की योग्यता और अनुभव पर अधिक आवश्यकताएं लगाता है।

6) गुम सूचकांक (विशेषकर जटिल प्रश्नों में) आम तौर पर आवश्यकता से अधिक उच्च स्तर की लॉकिंग की घटना का मुख्य कारक होते हैं। वे। विरोधाभास, एक तरफ, मैंने कहा कि क्वेरी को अनुकूलित करने से पहले मैंने कहा था कि आपको पहले ताले को देखने की ज़रूरत है, लेकिन अब मैं कहता हूं कि ताले को अनुकूलित करने के लिए, आपको क्वेरी को अनुकूलित करने की आवश्यकता है। मेरे पास एक बहाना है, कॉन्फ़िगरेशन को प्रबंधित लॉक पर स्विच करने से गैर-इष्टतम क्वेरी में भी अनावश्यक लॉक कम हो जाते हैं। ऐसा लेन-देन अलगाव स्तर में कमी के कारण होता है, जो बदले में DBMS लॉक मैनेजर को अत्यधिक लॉक लगाने के कम कारण देता है।

अत्यधिक लॉकिंग के मुख्य कारण (उपरोक्त संक्षेप में बताएं)

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

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

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

हमारी सेवाओं का उपयोग करें और आपके पास निःशुल्क समस्या का विश्लेषण करने और समाधान ढूंढने के अधिक अवसर होंगे!

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

प्रोग्राम के फ़्रीज़ होने के कई कारण हो सकते हैं:

यदि आपके पास 64x है बिट प्रणाली(), और आप 32-बिट सिस्टम के लिए डिज़ाइन किया गया प्रोग्राम चला रहे हैं, तो सबसे अच्छा तो प्रोग्राम शुरू ही नहीं होगा, सबसे खराब स्थिति में यह रुक जाएगा। हालाँकि यहाँ एक बारीकियाँ है - ऐसा होता है कि ऐसे कार्यक्रम काम करते हैं, लेकिन या तो गलत तरीके से काम करते हैं या समय के साथ रुक जाते हैं।

आपके पास चलाने के लिए बहुत कम RAM है.

आपके पास बहुत सारे प्रोग्राम और प्रक्रियाएं चल रही हैं जो पहले से ही सिस्टम को लोड कर रही हैं।

आपके पास पृष्ठभूमि में प्रोग्राम चल रहे हैं जो बहुत सारे सिस्टम संसाधन लेते हैं

वायरस

तकनीकी समस्याएँ (प्रोसेसर पर थर्मल पेस्ट सूख गया है, बहुत अधिक धूल जमा हो गई है, "कमजोर" हार्डवेयर, आदि)

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

के लिए उस प्रोग्राम को समाप्त करें जो प्रतिक्रिया नहीं दे रहा है(इसे फ्रीजिंग भी कहा जाता है) आपको टास्क मैनेजर को कॉल करना होगा। बेशक, आप उपयोग कर सकते हैं Ctrl+बदलाव+ईएससी, लेकिन मैं अधिक प्रसिद्ध और प्रभावी कीबोर्ड शॉर्टकट का उपयोग करने की सलाह देता हूं Ctrl+वैकल्पिक+डेल.

विंडोज 7 में जब आप इन कुंजियों को दबाएंगे तो पांच विकल्पों की एक विंडो खुलेगी जिसमें आपको आखिरी वाले को चुनना होगा।

टैब में अनुप्रयोगहम एक जमे हुए प्रोग्राम की तलाश करते हैं (आमतौर पर इसकी स्थिति जवाब नहीं दे रही है), उस पर राइट-क्लिक करें और मेनू से चयन करें प्रोसेस पर जाएं:

एक टैब खुलेगा प्रक्रियाओंएक समर्पित त्रिशंकु प्रक्रिया के साथ। यहां हम बस क्लिक करते हैं प्रक्रिया समाप्त करें

और सिस्टम चेतावनी से सहमत हों

टिप्पणी:
बेशक, आप टास्क मैनेजर मेनू में चयन नहीं कर सकते प्रोसेस पर जाएं, ए कार्य रद्द करेंऔर यह अधिक "कोमल" तरीका होगा, लेकिन कभी-कभी यह मदद नहीं करता है। और मैं किसी तरह ऐसी समस्याओं को प्रभावी ढंग से हल करने का आदी हूं।

इस तरह आप कंप्यूटर को पुनरारंभ किए बिना जमे हुए प्रोग्राम को "हटा" सकते हैं और अन्य चल रहे प्रोग्रामों को बरकरार रख सकते हैं।

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

लेकिन यहाँ याद रखना महत्वपूर्ण है एक विवरण: एक्सप्लोरर प्रक्रिया को explorer.exe कहा जाता है और जब यह समाप्त होगी, तो आपके कंप्यूटर के सभी फ़ोल्डर बंद हो जाएंगे। लेकिन यह आधी परेशानी है. आपके द्वारा एक्सप्लोरर को "मारने" के बाद, स्टार्ट मेनू वाला नियंत्रण कक्ष भी गायब हो जाएगा। इसीलिए कार्य प्रबंधक को तुरंत बंद न करें!जो गायब है उसे वापस करने के लिए (खुले फ़ोल्डरों को छोड़कर), फ़ाइल -> चलाएँ पर क्लिक करें

और पंक्ति में explorer.exe दर्ज करें

बेशक, ओके पर क्लिक करें और सब कुछ अपनी जगह पर वापस आ जाएगा।

इसे लाईक करें सरल तरीकासमस्या को ठीक करने के लिए यदि प्रोग्राम प्रतिसाद नहीं देता है या रुक जाता है तो क्या करें.

यह लेख मुख्य कारकों पर चर्चा करता है: जब 1C धीमा हो जाता है, 1C जम जाता है और 1C धीरे-धीरे काम करता है। डेटा 1सी + एमएस एसक्यूएल संयोजन पर निर्मित बड़े आईटी सिस्टम को अनुकूलित करने में सॉफ्टप्वाइंट के कई वर्षों के अनुभव के आधार पर तैयार किया गया था।

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

अभ्यास से: अनुकूलन करने का सबसे आसान तरीका 1C v7.7 है (1C 8.1, 1C 8.2, 1C 8.3 का अनुकूलन अधिक कठिन कार्य है, क्योंकि एप्लिकेशन में 3 लिंक होते हैं)। इसे एक साथ 400 उपयोगकर्ताओं तक लाना एक काफी विशिष्ट परियोजना है। 1500 तक पहुंचना पहले से ही कठिन है और इसके लिए कड़ी मेहनत की आवश्यकता होती है।

दूसरा मिथक: 1C के प्रदर्शन को बेहतर बनाने और 1C फ़्रीज़ से छुटकारा पाने के लिए, आपको एक अधिक शक्तिशाली सर्वर स्थापित करने की आवश्यकता है। एक नियम के रूप में, 95% मामलों में अनुकूलन परियोजनाओं में या तो बिना किसी अपग्रेड के स्वीकार्य संकेतक प्राप्त करना संभव है, या उपकरण के एक छोटे से हिस्से को अपडेट करके, उदाहरण के लिए, जोड़कर टक्कर मारना. यह ध्यान दिया जाना चाहिए कि उपकरण अभी भी सर्वर-आधारित होना चाहिए, विशेषकर डिस्क सबसिस्टम। पुराना डिस्क सबसिस्टम 1C के धीमी गति से काम करने का एक कारण है।

1C में बहु-उपयोगकर्ता कार्य करते समय मुख्य सीमा लॉकिंग तंत्र है। यह 1C में अवरोधन है, न कि सर्वर उपकरण, जो आमतौर पर बड़ी संख्या में लोगों को डेटाबेस में काम करने से रोकता है। इस समस्या को दूर करने के लिए, आपको कड़ी मेहनत करनी होगी और लॉकिंग लॉजिक को 1C में बदलना होगा - उन्हें सारणीबद्ध से पंक्ति-आधारित तक कम करना होगा। फिर, उदाहरण के लिए, किसी दस्तावेज़ को पोस्ट करने से सिस्टम में केवल एक ही ब्लॉक होगा, सभी दस्तावेज़ नहीं।

चित्र 1. PerfExpert मॉनिटरिंग सिस्टम में 1C ब्लॉकिंग कतार, 1C उपयोगकर्ताओं, एक कॉन्फ़िगरेशन मॉड्यूल और इस मॉड्यूल में कोड की एक विशिष्ट लाइन के बारे में जानकारी के साथ।

1सी लॉकिंग तंत्र को बदलना एक बहुत ही जटिल तकनीक है। हर कोई ऐसी चाल नहीं अपना सकता, और उनके लिए केवल एक ही रास्ता बचा है - संरचना को अनुकूलित करना और संचालन के निष्पादन समय को तेज करना। तथ्य यह है कि 1C में अवरोधन और संचालन के निष्पादन का समय अत्यधिक परस्पर संबंधित संकेतक हैं। उदाहरण के लिए, यदि किसी दस्तावेज़ को पोस्ट करने की कार्रवाई में 15 सेकंड लगते हैं, तो कब बड़ी मात्रा मेंउपयोगकर्ताओं, इस बात की बहुत अधिक संभावना है कि लेन-देन के दौरान कोई अन्य व्यक्ति दस्तावेज़ को स्थानांतरित करने का प्रयास करेगा और ब्लॉक होने का इंतज़ार करेगा। यदि आप निष्पादन समय को कम से कम 1 सेकंड तक बढ़ाते हैं, तो इस ऑपरेशन के लिए 1C अवरोधन काफी कम हो जाएगा।

ब्लॉकिंग की दृष्टि से अधिक खतरनाक ग्रुप प्रोसेसिंग है, जिसे पूरा होने में काफी समय लग सकता है और साथ ही 1सी ब्लॉकिंग भी हो सकती है। कोई भी प्रसंस्करण जो डेटा को बदलता है, उदाहरण के लिए, दस्तावेजों के अनुक्रम या बैच प्रसंस्करण को पुनर्स्थापित करना, तालिकाओं को लॉक कर देता है और अन्य उपयोगकर्ताओं को दस्तावेज़ पोस्ट करने से रोकता है। स्वाभाविक रूप से, ये प्रक्रियाएँ जितनी तेजी से निष्पादित की जाती हैं कम समयब्लॉक करना और उपयोगकर्ताओं के लिए काम करना आसान बनाता है।

भारी रिपोर्टें जो केवल-पढ़ने के लिए ऑपरेशन करती हैं, लॉकिंग के मामले में भी खतरनाक हो सकती हैं, हालांकि ऐसा प्रतीत होता है कि वे डेटा को लॉक नहीं करते हैं। ऐसी रिपोर्टें 1C में ब्लॉकिंग की तीव्रता को प्रभावित करती हैं, जिससे सिस्टम में अन्य ऑपरेशन धीमे हो जाते हैं। अर्थात्, यदि रिपोर्ट बहुत भारी है और सर्वर के संसाधनों का बड़ा हिस्सा लेती है, तो यह पता चल सकता है कि रिपोर्ट लॉन्च होने से पहले, वही ऑपरेशन 1 सेकंड के लिए किए गए थे, और रिपोर्ट निष्पादन के दौरान उन्हें 15 सेकंड के लिए निष्पादित किया गया था। . स्वाभाविक रूप से, जैसे-जैसे संचालन का निष्पादन समय बढ़ेगा, अवरोधन की तीव्रता भी बढ़ेगी।

चित्र 2. सभी उपयोगकर्ताओं से कॉन्फ़िगरेशन मॉड्यूल के संदर्भ में कार्यशील सर्वर पर लोड करें। प्रत्येक मॉड्यूल का अपना रंग होता है। 1C से निर्मित भार में स्पष्ट असंतुलन है।

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

भारी रिपोर्ट लॉन्च करने के अलावा, MS SQL और MS Windows की गैर-इष्टतम सेटिंग्स संचालन के निष्पादन समय को धीमा कर सकती हैं और इसलिए, 1C ब्लॉकिंग की तीव्रता को बढ़ा सकती हैं। यह समस्या 95% ग्राहकों में होती है। यह ध्यान दिया जाना चाहिए कि ये गंभीर संगठनों के सर्वर हैं; उच्च योग्य प्रशासकों के पूरे विभाग उनके समर्थन और कॉन्फ़िगरेशन में लगे हुए हैं।

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

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

पहली नज़र में, तस्वीर स्पष्ट है - आपको 1C सर्वर के संचालन को धीमा करने वाली हर चीज़ को अनुकूलित करने की आवश्यकता है। लेकिन आइए ऐसे ऑप्टिमाइज़र के स्थान पर खुद की कल्पना करें - मान लें कि हमारे पास 1C 8.1 8.2 8.3 UPP है और 50 उपयोगकर्ता एक ही समय में काम कर रहे हैं। एक भयानक दिन, उपयोगकर्ता शिकायत करने लगे कि 1C धीमा है, और हमें इस समस्या को हल करने की आवश्यकता है।

सबसे पहले, हम देखते हैं कि सर्वर पर क्या हो रहा है - क्या होगा यदि कोई विशेष रूप से स्वतंत्र एंटीवायरस सिस्टम का पूर्ण स्कैन कर रहा हो। एक निरीक्षण से पता चलता है कि सब कुछ ठीक है - सर्वर 100% पर लोड है, और केवल sqlservr प्रक्रिया द्वारा।

अभ्यास से: कनिष्ठ प्रशासकों में से एक ने, अपनी पहल पर, सर्वर पर ऑटो-अपडेट चालू कर दिया, विंडोज और एसक्यूएल खुशी-खुशी अपडेट हो गए, और अपडेट के बाद, 1C उपयोगकर्ताओं के काम में भारी मंदी शुरू हो गई, या 1C बस बंद हो गया।

अगला कदम यह जांचना है कि कौन से प्रोग्राम MS SQL को लोड करते हैं। निरीक्षण से पता चलता है कि लोड लगभग 20 एप्लिकेशन सर्वर कनेक्शन द्वारा उत्पन्न होता है।

अभ्यास से: एक प्रोग्राम जो किसी वेबसाइट पर डेटा को तुरंत अपडेट करता है, एक लूप में चला गया, और हर 4 घंटे में एक बार अपडेट करने के बजाय, उसने इसे लगातार किया, बिना रुके, सर्वर पर भारी लोड किया और डेटा को ब्लॉक कर दिया।

स्थिति के आगे के विश्लेषण में बड़ी कठिनाइयों का सामना करना पड़ता है। हम पहले ही पता लगा चुके हैं कि लोड सीधे 1C से आता है, लेकिन हम कैसे समझ सकते हैं कि उपयोगकर्ता वास्तव में क्या कर रहे हैं? या कम से कम वे कौन हैं. यह अच्छा है अगर किसी संगठन में 10 1सी उपयोगकर्ता हैं, तो आप बस उनके माध्यम से जा सकते हैं और पता लगा सकते हैं कि वे अब क्या कर रहे हैं, लेकिन हमारे मामले में उनमें से पचास हैं, और वे कई इमारतों में बिखरे हुए हैं।

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

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

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

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

किसी भी स्थिति में, 1सी प्रदर्शन समस्याओं को हल करने के लिए, हम अनुशंसा करते हैं कि आप पहले प्रदर्शन निगरानी खरीदें और उसका उपयोग करेंपरफेक्ट एक्सपर्ट , इससे आप सही निर्णय ले सकेंगे प्रबंधन निर्णयऔर पैसे बचाएं. यह उत्पाद छोटे 1C:एंटरप्राइज़ IS दोनों के लिए उपयुक्त है - 50 उपयोगकर्ताओं तक, और सिस्टम के लिए - 1000 उपयोगकर्ताओं तक। जुलाई 2015 से प्रदर्शन की निगरानीपरफेक्ट एक्सपर्ट 1सी:संगत प्रमाणपत्र प्राप्त हुआ, परीक्षण में उत्तीर्ण हुआमाइक्रोसॉफ्ट और न केवल 1C सिस्टम के लिए, बल्कि उस पर आधारित अन्य सूचना प्रणालियों के लिए भी प्रदर्शन समस्याओं को हल करने में मदद करता है MS SQL सर्वर (Axapta, CRM Dynamics, Doc Vision और अन्य)।

यदि आपको जानकारी पसंद आई, तो आगे की कार्रवाई की अनुशंसा करें:

- यदि आप 1सी प्रदर्शन (1सी 7.7, 1सी 8.1, 1सी 8.2) की तकनीकी समस्याओं से स्वतंत्र रूप से निपटना चाहते हैं।1सी 8.3) और अन्य सूचना प्रणालियाँ, तो आपके लिए हमारे पंचांग में तकनीकी लेखों की एक अनूठी सूची है (अवरुद्ध और गतिरोध, सीपीयू और डिस्क पर भारी भार, डेटाबेस रखरखाव और इंडेक्स ट्यूनिंग तकनीकी सामग्रियों का एक छोटा सा हिस्सा है जो आपको वहां मिलेगा)।
.
- यदि आप हमारे विशेषज्ञ के साथ प्रदर्शन संबंधी मुद्दों पर चर्चा करना चाहते हैं या परफएक्सपर्ट प्रदर्शन निगरानी समाधान का ऑर्डर देना चाहते हैं, फिर एक अनुरोध छोड़ें और हम यथाशीघ्र आपसे संपर्क करेंगे।