नए सर्वर पर 1s धीमा क्यों है? स्वचालन युक्तियाँ

यह आलेख मुख्य कारकों पर चर्चा करता है: जब 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 उपयोगकर्ताओं, एक कॉन्फ़िगरेशन मॉड्यूल और इस मॉड्यूल में कोड की एक विशिष्ट लाइन के बारे में जानकारी के साथ।

1C लॉकिंग तंत्र को बदलना एक बहुत ही जटिल तकनीक है। हर कोई ऐसी चाल नहीं अपना सकता, और उनके लिए केवल एक ही रास्ता बचा है - संरचना को अनुकूलित करना और संचालन के निष्पादन समय को तेज करना। तथ्य यह है कि 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:एंटरप्राइज़ सूचना सिस्टम - 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) और अन्य सूचना प्रणालियाँ, तो आपके लिए हमारे पंचांग में तकनीकी लेखों की एक अनूठी सूची है (अवरुद्ध और गतिरोध, सीपीयू और डिस्क पर भारी भार, डेटाबेस रखरखाव और इंडेक्स ट्यूनिंग तकनीकी सामग्रियों का एक छोटा सा हिस्सा है जो आपको वहां मिलेगा)।
.
- यदि आप हमारे विशेषज्ञ के साथ प्रदर्शन संबंधी मुद्दों पर चर्चा करना चाहते हैं या परफएक्सपर्ट प्रदर्शन निगरानी समाधान का ऑर्डर देना चाहते हैं, फिर एक अनुरोध छोड़ें और हम यथाशीघ्र आपसे संपर्क करेंगे।

हमें अक्सर इस बारे में प्रश्न मिलते हैं कि 1सी को धीमा करने का क्या कारण है, विशेष रूप से संस्करण 1सी 8.3 पर स्विच करते समय, इंटरफ़ेस एलएलसी के हमारे सहयोगियों के लिए धन्यवाद, हम आपको विस्तार से बताते हैं:

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

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

संसाधन की खपत, पहली नज़र

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

परीक्षण के लिए, हमने क्रमशः विंडोज सर्वर 2012 आर2 और विंडोज 8.1 चलाने वाली दो वर्चुअल मशीनें लीं, जिससे उन्हें होस्ट कोर i5-4670 के 2 कोर और 2 जीबी रैम मिली, जो लगभग एक औसत कार्यालय मशीन से मेल खाती है। सर्वर को दो WD Se की RAID 0 सरणी पर रखा गया था, और क्लाइंट को सामान्य प्रयोजन डिस्क की समान सरणी पर रखा गया था।

प्रायोगिक आधार के रूप में, हमने अकाउंटिंग 2.0, रिलीज़ के कई कॉन्फ़िगरेशन का चयन किया 2.0.64.12 , जिसे बाद में अद्यतन किया गया 3.0.38.52 , सभी कॉन्फ़िगरेशन प्लेटफ़ॉर्म पर लॉन्च किए गए थे 8.3.5.1443 .

पहली चीज़ जो ध्यान आकर्षित करती है वह ट्रोइका के सूचना आधार का बढ़ा हुआ आकार है, जो काफी बढ़ गया है, साथ ही रैम के लिए बहुत अधिक भूख भी है:

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

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

चयनित क्रियाओं को लागू करने के बाद, डेटाबेस ने तेजी से "वजन कम किया", "दो" से भी छोटा हो गया, जिसे किसी ने कभी भी अनुकूलित नहीं किया था, और रैम की खपत भी थोड़ी कम हो गई।

इसके बाद, नए क्लासिफायर और निर्देशिकाओं को लोड करने, इंडेक्स बनाने आदि के बाद। आधार का आकार बढ़ जाएगा; सामान्य तौर पर, "तीन" आधार "दो" आधारों से बड़े होते हैं। हालाँकि, यह अधिक महत्वपूर्ण नहीं है, यदि दूसरा संस्करण 150-200 एमबी रैम से संतुष्ट था, तो नए संस्करण को आधा गीगाबाइट की आवश्यकता होती है और कार्यक्रम के साथ काम करने के लिए आवश्यक संसाधनों की योजना बनाते समय इस मूल्य को ध्यान में रखा जाना चाहिए।

जाल

नेटवर्क बैंडविड्थ नेटवर्क अनुप्रयोगों के लिए सबसे महत्वपूर्ण मापदंडों में से एक है, विशेष रूप से फ़ाइल मोड में 1C की तरह, जो पूरे नेटवर्क में महत्वपूर्ण मात्रा में डेटा स्थानांतरित करता है। छोटे उद्यमों के अधिकांश नेटवर्क सस्ते 100 Mbit/s उपकरण के आधार पर बनाए जाते हैं, इसलिए हमने 100 Mbit/s और 1 Gbit/s नेटवर्क में 1C प्रदर्शन संकेतकों की तुलना करके परीक्षण शुरू किया।

जब आप नेटवर्क पर 1C फ़ाइल डेटाबेस लॉन्च करते हैं तो क्या होता है? क्लाइंट काफी बड़ी मात्रा में जानकारी अस्थायी फ़ोल्डरों में डाउनलोड करता है, खासकर यदि यह पहली, "ठंडी" शुरुआत है। 100 एमबीटी/एस पर, हमसे चैनल की चौड़ाई के विपरीत चलने की उम्मीद की जाती है और डाउनलोड में काफी समय लग सकता है, हमारे मामले में लगभग 40 सेकंड (ग्राफ़ को विभाजित करने की लागत 4 सेकंड है)।

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

जैसा कि आप ग्राफ़ से देख सकते हैं, अकाउंटिंग 2.0 किसी भी नेटवर्क स्पीड पर दोगुनी तेजी से लोड होता है, 100 Mbit/s से 1 Gbit/s में संक्रमण आपको डाउनलोड समय को चार गुना तेज करने की अनुमति देता है। इस मोड में अनुकूलित और गैर-अनुकूलित "ट्रोइका" डेटाबेस के बीच कोई अंतर नहीं है।

हमने हेवी मोड में ऑपरेशन पर नेटवर्क स्पीड के प्रभाव की भी जांच की, उदाहरण के लिए, ग्रुप ट्रांसफर के दौरान। परिणाम सापेक्ष मूल्यों में भी व्यक्त किया गया है:

यहां यह अधिक दिलचस्प है, 100 Mbit/s नेटवर्क में "तीन" का अनुकूलित आधार "दो" के समान गति से काम करता है, और गैर-अनुकूलित आधार दोगुने खराब परिणाम दिखाता है। गीगाबिट पर, अनुपात समान रहता है, अअनुकूलित "तीन" भी "दो" की तुलना में आधा धीमा है, और अनुकूलित एक तिहाई से पीछे है। साथ ही, 1 Gbit/s में परिवर्तन आपको संस्करण 2.0 के लिए निष्पादन समय को तीन गुना और संस्करण 3.0 के लिए आधे तक कम करने की अनुमति देता है।

रोजमर्रा के काम पर नेटवर्क स्पीड के प्रभाव का मूल्यांकन करने के लिए, हमने प्रयोग किया परफॉरमेंस नापना, प्रत्येक डेटाबेस में पूर्व निर्धारित क्रियाओं का अनुक्रम निष्पादित करना।

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

किए गए परीक्षणों से, यह स्पष्ट हो जाता है कि नेटवर्क नए कॉन्फ़िगरेशन के लिए कोई बाधा नहीं है, और प्रबंधित एप्लिकेशन सामान्य से भी अधिक तेज़ चलता है। यदि भारी कार्य और डेटाबेस लोडिंग गति आपके लिए महत्वपूर्ण है, तो आप 1 Gbit/s पर स्विच करने की अनुशंसा भी कर सकते हैं, अन्य मामलों में, नए कॉन्फ़िगरेशन आपको धीमे 100 Mbit/s नेटवर्क में भी प्रभावी ढंग से काम करने की अनुमति देते हैं;

तो 1C धीमा क्यों है? हम इस पर आगे गौर करेंगे।

सर्वर डिस्क सबसिस्टम और एसएसडी

पिछले लेख में, हमने SSD पर डेटाबेस रखकर 1C प्रदर्शन में वृद्धि हासिल की थी। शायद सर्वर के डिस्क सबसिस्टम का प्रदर्शन अपर्याप्त है? हमने एक साथ दो डेटाबेस में समूह चलाने के दौरान डिस्क सर्वर के प्रदर्शन को मापा और एक आशावादी परिणाम प्राप्त किया।

प्रति सेकंड इनपुट/आउटपुट संचालन की अपेक्षाकृत बड़ी संख्या (आईओपीएस) - 913 के बावजूद, कतार की लंबाई 1.84 से अधिक नहीं थी, जो दो-डिस्क सरणी के लिए एक बहुत अच्छा परिणाम है। इसके आधार पर, हम यह अनुमान लगा सकते हैं कि साधारण डिस्क से बना दर्पण भारी मोड में 8-10 नेटवर्क क्लाइंट के सामान्य संचालन के लिए पर्याप्त होगा।

तो क्या सर्वर पर SSD की आवश्यकता है? इस प्रश्न का उत्तर देने का सबसे अच्छा तरीका परीक्षण के माध्यम से होगा, जिसे हमने एक समान विधि का उपयोग करके किया था, नेटवर्क कनेक्शन हर जगह 1 Gbit/s है, परिणाम भी सापेक्ष मूल्यों में व्यक्त किया गया है।

आइए डेटाबेस की लोडिंग गति से शुरुआत करें।

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

आइए पुनः करने की ओर आगे बढ़ें:

हमने पहले ही ऊपर उल्लेख किया है कि भारी मोड में काम करने के लिए भी डिस्क का प्रदर्शन काफी पर्याप्त है, इसलिए एसएसडी की गति भी प्रभावित नहीं होती है, सिवाय गैर-अनुकूलित आधार के, जिसने एसएसडी पर अनुकूलित आधार को पकड़ लिया है। दरअसल, यह एक बार फिर पुष्टि करता है कि अनुकूलन ऑपरेशन डेटाबेस में जानकारी को व्यवस्थित करते हैं, यादृच्छिक I/O संचालन की संख्या को कम करते हैं और उस तक पहुंच की गति को बढ़ाते हैं।

रोजमर्रा के कार्यों में चित्र समान है:

SSD से केवल गैर-अनुकूलित डेटाबेस को ही लाभ होता है। बेशक, आप SSD खरीद सकते हैं, लेकिन डेटाबेस के समय पर रखरखाव के बारे में सोचना बेहतर होगा। साथ ही, सर्वर पर इन्फोबेस वाले अनुभाग को डीफ़्रैग्मेन्ट करने के बारे में भी न भूलें।

क्लाइंट डिस्क सबसिस्टम और एसएसडी

हमने पिछली सामग्री में स्थानीय रूप से स्थापित 1सी के संचालन की गति पर एसएसडी के प्रभाव पर चर्चा की थी; जो कुछ कहा गया था वह नेटवर्क मोड में काम करने के लिए भी सच है। दरअसल, 1C पृष्ठभूमि और नियमित कार्यों सहित डिस्क संसाधनों का काफी सक्रिय रूप से उपयोग करता है। नीचे दिए गए चित्र में आप देख सकते हैं कि कैसे अकाउंटिंग 3.0 लोड होने के बाद लगभग 40 सेकंड तक डिस्क तक सक्रिय रूप से पहुंचता है।

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

एक धीमी हार्ड ड्राइव कुछ कार्यों को धीमा कर सकती है, लेकिन अपने आप में किसी प्रोग्राम को धीमा नहीं कर सकती।

टक्कर मारना

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

हमने सिस्टम मेमोरी को घटाकर 1 जीबी कर दिया और दो सूचना डेटाबेस लॉन्च किए।

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

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

जैसा कि हम देख सकते हैं, सिस्टम डेटा प्राप्त करने के लिए सक्रिय रूप से नेटवर्क का उपयोग करता है और इसे संसाधित करने के लिए प्रोसेसर; प्रसंस्करण के दौरान डिस्क गतिविधि नगण्य है, यह कभी-कभी बढ़ जाती है, लेकिन यह एक सीमित कारक नहीं है;

अब मेमोरी को 1 जीबी तक कम करते हैं:

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

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

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

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

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

CPU

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

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

निष्कर्ष

तो, 1C धीमा क्यों है? सबसे पहले, यह रैम की कमी है; इस मामले में मुख्य भार हार्ड ड्राइव और प्रोसेसर पर पड़ता है। और यदि वे प्रदर्शन के साथ चमकते नहीं हैं, जैसा कि आमतौर पर कार्यालय कॉन्फ़िगरेशन में होता है, तो हमें लेख की शुरुआत में वर्णित स्थिति मिलती है - "दो" ने ठीक काम किया, लेकिन "तीन" बेहद धीमी गति से हैं।

दूसरे स्थान पर नेटवर्क प्रदर्शन है; एक धीमा 100 Mbit/s चैनल एक वास्तविक बाधा बन सकता है, लेकिन साथ ही, पतला क्लाइंट मोड धीमे चैनलों पर भी संचालन के काफी आरामदायक स्तर को बनाए रखने में सक्षम है।

फिर आपको डिस्क ड्राइव पर ध्यान देना चाहिए; SSD खरीदना एक अच्छा निवेश होने की संभावना नहीं है, लेकिन ड्राइव को अधिक आधुनिक से बदलना एक अच्छा विचार होगा। हार्ड ड्राइव की पीढ़ियों के बीच अंतर का आकलन निम्नलिखित सामग्री से किया जा सकता है: 500 जीबी और 1 टीबी की दो सस्ती वेस्टर्न डिजिटल ब्लू श्रृंखला ड्राइव की समीक्षा।

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

हमें उम्मीद है कि यह सामग्री आपको "1C धीमा क्यों है" प्रश्न को शीघ्रता से समझने और इसे सबसे प्रभावी ढंग से और अतिरिक्त लागत के बिना हल करने में मदद करेगी।

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

आइए एक रूपक की ओर मुड़ें: यह पता लगाने से पहले कि कोई व्यक्ति कहीं क्यों नहीं आया, आपको यह सुनिश्चित करना चाहिए कि उसके पास चलने के लिए पैर हैं। तो, आइए हार्डवेयर और नेटवर्क आवश्यकताओं से शुरुआत करें।

यदि विंडोज 7 स्थापित है:

यदि आपके पास विंडोज़ 8 या 10 स्थापित है:



यह भी याद रखें कि कम से कम 2 जीबी खाली डिस्क स्थान होना चाहिए, और नेटवर्क कनेक्शन की गति कम से कम 100 एमबी/सेकंड होनी चाहिए।

क्लाइंट-सर्वर संस्करण में सर्वर की विशेषताओं पर विचार करने का कोई मतलब नहीं है, क्योंकि इस मामले में सब कुछ उपयोगकर्ताओं की संख्या और उन कार्यों की बारीकियों पर निर्भर करता है जो वे 1C में हल करते हैं।

सर्वर कॉन्फ़िगरेशन चुनते समय, निम्नलिखित को ध्यान में रखें:

  • एक 1C सर्वर वर्कर प्रक्रिया में औसतन 4 जीबी की खपत होती है (उपयोगकर्ता कनेक्शन के साथ भ्रमित न हों, क्योंकि एक वर्कर प्रक्रिया में उतने कनेक्शन हो सकते हैं जितने आप सर्वर सेटिंग्स में निर्दिष्ट करते हैं);
  • एक भौतिक सर्वर पर 1सी और एक डीबीएमएस (विशेष रूप से एमएस एसक्यूएल) का उपयोग बड़ी मात्रा में डेटा संसाधित करते समय लाभ देता है (उदाहरण के लिए, एक महीने को बंद करना, एक मॉडल के आधार पर बजट की गणना करना, आदि), लेकिन अनलोड किए गए संचालन के दौरान प्रदर्शन को काफी कम कर देता है ( उदाहरण के लिए, कार्यान्वयन दस्तावेज़ बनाना और संचालित करना, आदि);
  • याद रखें कि 1सी सर्वर और डीबीएमएस को 1 जीबी के "मोटे" चैनल पर जोड़ा जाना चाहिए;
  • उच्च-प्रदर्शन डिस्क का उपयोग करें और 1C सर्वर और DBMS भूमिकाओं को अन्य भूमिकाओं (उदाहरण के लिए, फ़ाइल, AD, डोमेन नियंत्रक, आदि) के साथ संयोजित न करें।

यदि उपकरण की जाँच के बाद भी 1C धीमा हो जाता है

हमारी एक छोटी सी कंपनी है, 7 लोग हैं, और 1सी धीमा है। हमने विशेषज्ञों से संपर्क किया और उन्होंने कहा कि केवल क्लाइंट-सर्वर विकल्प ही हमें बचाएगा। लेकिन हमारे लिए ऐसा समाधान स्वीकार्य नहीं है, यह बहुत महंगा है!

डेटाबेस में नियमित रखरखाव करें*:

1. डेटाबेस को कॉन्फिगरेटर मोड में लॉन्च करें।


2. मुख्य मेनू में "प्रशासन" चुनें, और उसमें - "परीक्षण और सुधार"।


3. चित्र के अनुसार सभी बक्सों की जाँच करें। चलाएँ पर क्लिक करें.

*डेटाबेस के आकार और आपके पीसी की विशेषताओं के आधार पर इस प्रक्रिया में 15 मिनट से एक घंटे तक का समय लग सकता है।

यदि इससे मदद नहीं मिलती है, तो हम क्लाइंट-सर्वर कनेक्शन बनाते हैं, लेकिन हार्डवेयर और सॉफ्टवेयर में अतिरिक्त निवेश के बिना:

1. कार्यालय में सबसे कम लोड वाला डेस्कटॉप कंप्यूटर चुनें (नोटबुक नहीं): इसमें कम से कम 4 जीबी रैम और कम से कम 100 एमबी/सेकंड का नेटवर्क कनेक्शन होना चाहिए।

2. इस पर IIS (इंटरनेट सूचना सर्वर) सक्रिय करें। इसके लिए:





3. इस कंप्यूटर पर अपना डेटाबेस प्रकाशित करें. इस विषय पर ITS पर सामग्री उपलब्ध है, या किसी सहायता विशेषज्ञ से संपर्क करें।

4. उपयोगकर्ता कंप्यूटर पर, एक पतले क्लाइंट के माध्यम से डेटाबेस तक पहुंच कॉन्फ़िगर करें। इसके लिए:


1सी लॉन्च विंडो खोलें।


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


"बेसिक स्टार्टअप मोड" स्विच को "थिन क्लाइंट" मोड पर सेट करें। "संपन्न" पर क्लिक करें।

हमारी एक बड़ी कंपनी है, लेकिन बहुत बड़ी नहीं, लगभग 50-60 लोग हम क्लाइंट-सर्वर विकल्प का उपयोग करते हैं, लेकिन 1सी बहुत धीमा है।

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

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

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

हम उस समय को रिकॉर्ड करते हैं जब दस्तावेज़ धीरे-धीरे संसाधित होते हैं, या वह समय और उपयोगकर्ता जिसके पास अवरोधन त्रुटि होती है।

पंजीकरण लॉग खोलें.



हमें इवेंट प्रकार "Data.Post" के साथ सही उपयोगकर्ता के लिए सही समय पर आवश्यक दस्तावेज़ मिल जाता है।



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

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

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

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

  • समानांतर और अतुल्यकालिक प्रोग्रामिंग प्रौद्योगिकियों का उपयोग करें जो 1C का समर्थन करता है (पृष्ठभूमि नौकरियां और लूप में क्वेरीज़)।
  • समाधान आर्किटेक्चर को डिज़ाइन करते समय, सबसे अधिक बाधा वाले क्षेत्रों में संचय रजिस्टर और लेखांकन रजिस्टर का उपयोग करने से बचें।
  • डेटा संरचना (संचय और/या सूचना रजिस्टर) विकसित करते समय, नियम का पालन करें: "लिखने और पढ़ने के लिए सबसे तेज़ तालिका एक कॉलम वाली तालिका है।" यदि आप विशिष्ट RAUSE तंत्र को देखें तो हम किस बारे में बात कर रहे हैं यह स्पष्ट हो जाएगा।
  • बड़ी मात्रा में डेटा संसाधित करने के लिए, सहायक क्लस्टर का उपयोग करें जहां एक ही डेटाबेस जुड़ा हुआ है (लेकिन किसी भी स्थिति में इंटरैक्टिव कार्य के दौरान ऐसा नहीं किया जाना चाहिए!!!)। यह आपको मानक 1C लॉक को बायपास करने की अनुमति देगा, जिससे डेटाबेस के साथ लगभग उसी गति से काम करना संभव हो जाएगा जैसे सीधे SQL टूल के साथ काम करते समय होता है।

यह ध्यान देने योग्य है कि होल्डिंग्स और बड़ी कंपनियों के लिए 1C अनुकूलन एक अलग, बड़े लेख का विषय है, इसलिए हमारी वेबसाइट पर अद्यतन सामग्री के लिए बने रहें।

2. कार्यक्रम की विशेषताएं. अक्सर, इष्टतम सेटिंग्स के साथ भी, 1C बहुत धीमी गति से काम करता है। प्रदर्शन विशेष रूप से तेजी से गिरता है जब डेटाबेस के साथ एक साथ काम करने वालों की संख्या 4-5 उपयोगकर्ताओं से अधिक हो जाती है।

आप कंपनी में कौन हैं?

धीमे 1सी संचालन की समस्या का समाधान इस बात पर निर्भर करता है कि आप कंपनी में कौन हैं। यदि आप तकनीकी विशेषज्ञ हैं, तो बस आगे पढ़ें। यदि आप निदेशक या लेखाकार हैं, तो विशेष लिंक ↓ का अनुसरण करें

नेटवर्क बैंडविड्थ

एक नियम के रूप में, एक नहीं, बल्कि कई उपयोगकर्ता एक सूचना आधार (आईएस) के साथ काम करते हैं। साथ ही, जिस कंप्यूटर पर 1सी क्लाइंट स्थापित है और जिस कंप्यूटर पर सूचना सुरक्षा स्थित है, उसके बीच डेटा का निरंतर आदान-प्रदान होता है। इस डेटा की मात्रा काफी महत्वपूर्ण है. ऐसी स्थिति अक्सर उत्पन्न होती है जब 100 Mbit/s की गति पर चलने वाला एक स्थानीय नेटवर्क, जो कि सबसे सामान्य गति है, लोड का सामना नहीं कर पाता है। और फिर से उपयोगकर्ता प्रोग्राम धीमा होने की शिकायत करता है।

इनमें से प्रत्येक कारक व्यक्तिगत रूप से पहले से ही कार्यक्रम की गति को काफी कम कर देता है, लेकिन सबसे अप्रिय बात यह है कि आमतौर पर ये चीजें बढ़ती हैं।

आइए अब 10 मध्यम आकार के कंप्यूटरों के स्थानीय नेटवर्क के उदाहरण का उपयोग करके कम 1C गति की समस्या और उनकी लागत के कई समाधान देखें।

समाधान एक. बुनियादी ढांचे का आधुनिकीकरण

यह शायद सबसे स्पष्ट समाधान है. आइए इसकी न्यूनतम लागत की गणना करें।

कम से कम, प्रत्येक कंप्यूटर के लिए हमें 2 जीबी रैम स्टिक की आवश्यकता होती है, जिसकी कीमत औसतन 1,500 रूबल होती है, 1 जीबीपीएस की गति का समर्थन करने वाले नेटवर्क कार्ड की लागत लगभग 700 रूबल होती है। इसके अतिरिक्त, आपको कम से कम 1 राउटर की आवश्यकता होगी जो 1 Gbit/s की गति का समर्थन करता हो, जिसकी लागत लगभग 4,000 रूबल होगी। कुल लागत - उपकरण के लिए 26,000 रूबल, काम को छोड़कर।

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

समाधान दो. टर्मिनल सर्वर

1सी 7 के दिनों में इसे बहुत लोकप्रियता मिली। यह विंडोज़ के सर्वर संस्करण पर लागू किया गया है और हमारे कार्य को अच्छी तरह से पूरा करता है। हालाँकि, इसके अपने नुकसान हैं, अर्थात् लाइसेंस की लागत।

ऑपरेटिंग सिस्टम की लागत लगभग 40,000 रूबल होगी। इसके अलावा, हमें उन सभी लोगों के लिए एक विंडोज़ सर्वर सीएएल लाइसेंस की आवश्यकता होगी जो 1सी में काम करने की योजना बना रहे हैं, जिसकी कीमत लगभग 1,700 रूबल है, और एक विंडोज़ रिमोट डेस्कटॉप सर्विसेज सीएएल लाइसेंस है, जिसकी कीमत लगभग 5,900 रूबल है।

10 कंप्यूटरों के नेटवर्क की लागत की गणना करने के बाद, हमें 116,000 रूबल मिलते हैं। केवल एक लाइसेंस के लिए. इसमें सर्वर की लागत (कम से कम 40,000 रूबल) और कार्यान्वयन कार्य की लागत जोड़ें, हालांकि, इसके बिना भी, लाइसेंस की कीमत प्रभावशाली निकली।

समाधान तीन. सेवा 1सी एंटरप्राइज

1C ने इस समस्या का अपना समाधान विकसित किया है, जो प्रोग्राम की गति को काफी बढ़ा सकता है। लेकिन यहां एक बारीकियां भी है.

तथ्य यह है कि ऐसे समाधान की लागत संस्करण के आधार पर 50,000 से 80,000 रूबल तक होती है। 15 उपयोगकर्ताओं तक वाली कंपनी के लिए यह काफी महंगा साबित होता है। "1C एंटरप्राइज़ मिनी-सर्वर" पर बड़ी उम्मीदें लगाई गई थीं, जो कि 1C कंपनी के अनुसार, छोटे व्यवसायों के लिए है और इसकी लागत लगभग 10,000 - 15,000 रूबल है।

हालाँकि, जब यह बिक्री पर गया, तो यह उत्पाद एक बड़ी निराशा थी। तथ्य यह है कि मिनी-सर्वर का उपयोग करने वाले उपयोगकर्ताओं की अधिकतम संख्या केवल 5 थी।

जैसा कि एक 1C प्रोग्रामर ने फोरम पर लिखा: “यह अभी भी स्पष्ट नहीं है कि 1C ने बिल्कुल 5 कनेक्शन क्यों चुने! समस्याएँ केवल 4 उपयोगकर्ताओं के साथ शुरू होती हैं, लेकिन पाँच के साथ सब समाप्त हो जाती हैं। यदि आप छठे व्यक्ति को जोड़ना चाहते हैं, तो 50 हजार और भुगतान करें, हम कम से कम 10 कनेक्शन जोड़ सकते हैं..."

बेशक, मिनी सर्वर को भी अपना उपभोक्ता मिल गया। हालाँकि, उन कंपनियों के लिए जहां 5 या अधिक लोग 1C के साथ काम करते हैं, कोई सरल और सस्ता समाधान सामने नहीं आया है।

ऊपर वर्णित कार्यक्रम त्वरण विधियों के अलावा, एक और तरीका है जो 5 - 15 उपयोगकर्ताओं के खंड के लिए आदर्श है, अर्थात् फ़ाइल मोड में 1 सी के लिए वेब एक्सेस।

समाधान चार. फ़ाइल मोड में 1सी के लिए वेब एक्सेस

संचालन का सिद्धांत इस प्रकार है: कंप्यूटर पर एक वेब सर्वर की एक अतिरिक्त भूमिका स्थापित की जाती है, जिस पर सूचना सुरक्षा प्रकाशित होती है।

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

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

यह विकल्प ऑपरेटिंग गति के मामले में एंटरप्राइज़ 1C सर्वर से कमतर है, लेकिन 15-20 उपयोगकर्ताओं तक यह अंतर व्यावहारिक रूप से अदृश्य है। वैसे, एक वेब सर्वर को लागू करने के लिए आप IIS (विंडोज़ के लिए) और Apache (लिनक्स के लिए) का उपयोग कर सकते हैं और ये दोनों समाधान मुफ़्त हैं!

स्पष्ट लाभों के बावजूद, 1C ऑपरेशन को अनुकूलित करने की इस पद्धति को अधिक लोकप्रियता नहीं मिली है।

मैं निश्चित रूप से नहीं कह सकता, लेकिन संभवतः यह दो कारणों से है:

  • तकनीकी दस्तावेज़ में काफ़ी कमज़ोर वर्णन है
  • सिस्टम प्रशासक और 1सी प्रोग्रामर की जिम्मेदारी के चौराहे पर स्थित है

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

आइए 1C की गति बढ़ाएं। दूर से, शीघ्रता से और आपकी भागीदारी के बिना

हम जानते हैं कि ग्राहक को परेशान किए बिना 1स्की की गति कैसे बढ़ाई जाए। हम समस्या की गहराई में जाते हैं, अपना काम करते हैं और चले जाते हैं। यदि आप चाहते हैं कि प्रोग्राम सामान्य रूप से काम करे, तो हमसे संपर्क करें। हम यह पता लगा लेंगे।

एक अनुरोध छोड़ें और कार्यक्रम में तेजी लाने पर निःशुल्क परामर्श प्राप्त करें।

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

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

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

संसाधन की खपत, पहली नज़र

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

परीक्षण के लिए, हमने क्रमशः विंडोज सर्वर 2012 आर2 और विंडोज 8.1 चलाने वाली दो वर्चुअल मशीनें लीं, जिससे उन्हें होस्ट कोर i5-4670 के 2 कोर और 2 जीबी रैम मिली, जो लगभग एक औसत कार्यालय मशीन से मेल खाती है। सर्वर को दो की RAID 0 सरणी पर रखा गया था, और क्लाइंट को सामान्य प्रयोजन डिस्क की समान सरणी पर रखा गया था।

प्रायोगिक आधार के रूप में, हमने अकाउंटिंग 2.0, रिलीज़ के कई कॉन्फ़िगरेशन का चयन किया 2.0.64.12 , जिसे बाद में अद्यतन किया गया 3.0.38.52 , सभी कॉन्फ़िगरेशन प्लेटफ़ॉर्म पर लॉन्च किए गए थे 8.3.5.1443 .

पहली चीज़ जो ध्यान आकर्षित करती है वह ट्रोइका के सूचना आधार का बढ़ा हुआ आकार है, जो काफी बढ़ गया है, साथ ही रैम के लिए बहुत अधिक भूख भी है:

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

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

चयनित क्रियाओं को लागू करने के बाद, डेटाबेस ने तेजी से "वजन कम किया", "दो" से भी छोटा हो गया, जिसे किसी ने कभी भी अनुकूलित नहीं किया था, और रैम की खपत भी थोड़ी कम हो गई।

इसके बाद, नए क्लासिफायर और निर्देशिकाओं को लोड करने, इंडेक्स बनाने आदि के बाद। आधार का आकार बढ़ जाएगा; सामान्य तौर पर, "तीन" आधार "दो" आधारों से बड़े होते हैं। हालाँकि, यह अधिक महत्वपूर्ण नहीं है, यदि दूसरा संस्करण 150-200 एमबी रैम से संतुष्ट था, तो नए संस्करण को आधा गीगाबाइट की आवश्यकता होती है और कार्यक्रम के साथ काम करने के लिए आवश्यक संसाधनों की योजना बनाते समय इस मूल्य को ध्यान में रखा जाना चाहिए।

जाल

नेटवर्क बैंडविड्थ नेटवर्क अनुप्रयोगों के लिए सबसे महत्वपूर्ण मापदंडों में से एक है, विशेष रूप से फ़ाइल मोड में 1C की तरह, जो पूरे नेटवर्क में महत्वपूर्ण मात्रा में डेटा स्थानांतरित करता है। छोटे उद्यमों के अधिकांश नेटवर्क सस्ते 100 Mbit/s उपकरण के आधार पर बनाए जाते हैं, इसलिए हमने 100 Mbit/s और 1 Gbit/s नेटवर्क में 1C प्रदर्शन संकेतकों की तुलना करके परीक्षण शुरू किया।

जब आप नेटवर्क पर 1C फ़ाइल डेटाबेस लॉन्च करते हैं तो क्या होता है? क्लाइंट काफी बड़ी मात्रा में जानकारी अस्थायी फ़ोल्डरों में डाउनलोड करता है, खासकर यदि यह पहली, "ठंडी" शुरुआत है। 100 एमबीटी/एस पर, हमसे चैनल की चौड़ाई के विपरीत चलने की उम्मीद की जाती है और डाउनलोड में काफी समय लग सकता है, हमारे मामले में लगभग 40 सेकंड (ग्राफ़ को विभाजित करने की लागत 4 सेकंड है)।

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

जैसा कि आप ग्राफ़ से देख सकते हैं, अकाउंटिंग 2.0 किसी भी नेटवर्क स्पीड पर दोगुनी तेजी से लोड होता है, 100 Mbit/s से 1 Gbit/s में संक्रमण आपको डाउनलोड समय को चार गुना तेज करने की अनुमति देता है। इस मोड में अनुकूलित और गैर-अनुकूलित "ट्रोइका" डेटाबेस के बीच कोई अंतर नहीं है।

हमने हेवी मोड में ऑपरेशन पर नेटवर्क स्पीड के प्रभाव की भी जांच की, उदाहरण के लिए, ग्रुप ट्रांसफर के दौरान। परिणाम सापेक्ष मूल्यों में भी व्यक्त किया गया है:

यहां यह अधिक दिलचस्प है, 100 Mbit/s नेटवर्क में "तीन" का अनुकूलित आधार "दो" के समान गति से काम करता है, और गैर-अनुकूलित आधार दोगुने खराब परिणाम दिखाता है। गीगाबिट पर, अनुपात समान रहता है, अअनुकूलित "तीन" भी "दो" की तुलना में आधा धीमा है, और अनुकूलित एक तिहाई से पीछे है। साथ ही, 1 Gbit/s में परिवर्तन आपको संस्करण 2.0 के लिए निष्पादन समय को तीन गुना और संस्करण 3.0 के लिए आधे तक कम करने की अनुमति देता है।

रोजमर्रा के काम पर नेटवर्क स्पीड के प्रभाव का मूल्यांकन करने के लिए, हमने प्रयोग किया परफॉरमेंस नापना, प्रत्येक डेटाबेस में पूर्व निर्धारित क्रियाओं का अनुक्रम निष्पादित करना।

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

किए गए परीक्षणों से, यह स्पष्ट हो जाता है कि नेटवर्क नए कॉन्फ़िगरेशन के लिए कोई बाधा नहीं है, और प्रबंधित एप्लिकेशन सामान्य से भी अधिक तेज़ चलता है। यदि भारी कार्य और डेटाबेस लोडिंग गति आपके लिए महत्वपूर्ण है, तो आप 1 Gbit/s पर स्विच करने की अनुशंसा भी कर सकते हैं, अन्य मामलों में, नए कॉन्फ़िगरेशन आपको धीमे 100 Mbit/s नेटवर्क में भी प्रभावी ढंग से काम करने की अनुमति देते हैं;

तो 1C धीमा क्यों है? हम इस पर आगे गौर करेंगे।

सर्वर डिस्क सबसिस्टम और एसएसडी

पिछले लेख में, हमने SSD पर डेटाबेस रखकर 1C प्रदर्शन में वृद्धि हासिल की थी। शायद सर्वर के डिस्क सबसिस्टम का प्रदर्शन अपर्याप्त है? हमने एक साथ दो डेटाबेस में समूह चलाने के दौरान डिस्क सर्वर के प्रदर्शन को मापा और एक आशावादी परिणाम प्राप्त किया।

प्रति सेकंड इनपुट/आउटपुट संचालन की अपेक्षाकृत बड़ी संख्या (आईओपीएस) - 913 के बावजूद, कतार की लंबाई 1.84 से अधिक नहीं थी, जो दो-डिस्क सरणी के लिए एक बहुत अच्छा परिणाम है। इसके आधार पर, हम यह अनुमान लगा सकते हैं कि साधारण डिस्क से बना दर्पण भारी मोड में 8-10 नेटवर्क क्लाइंट के सामान्य संचालन के लिए पर्याप्त होगा।

तो क्या सर्वर पर SSD की आवश्यकता है? इस प्रश्न का उत्तर देने का सबसे अच्छा तरीका परीक्षण के माध्यम से होगा, जिसे हमने एक समान विधि का उपयोग करके किया था, नेटवर्क कनेक्शन हर जगह 1 Gbit/s है, परिणाम भी सापेक्ष मूल्यों में व्यक्त किया गया है।

आइए डेटाबेस की लोडिंग गति से शुरुआत करें।

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

आइए पुनः करने की ओर आगे बढ़ें:

हमने पहले ही ऊपर उल्लेख किया है कि भारी मोड में काम करने के लिए भी डिस्क का प्रदर्शन काफी पर्याप्त है, इसलिए एसएसडी की गति भी प्रभावित नहीं होती है, सिवाय गैर-अनुकूलित आधार के, जिसने एसएसडी पर अनुकूलित आधार को पकड़ लिया है। दरअसल, यह एक बार फिर पुष्टि करता है कि अनुकूलन ऑपरेशन डेटाबेस में जानकारी को व्यवस्थित करते हैं, यादृच्छिक I/O संचालन की संख्या को कम करते हैं और उस तक पहुंच की गति को बढ़ाते हैं।

रोजमर्रा के कार्यों में चित्र समान है:

SSD से केवल गैर-अनुकूलित डेटाबेस को ही लाभ होता है। बेशक, आप SSD खरीद सकते हैं, लेकिन डेटाबेस के समय पर रखरखाव के बारे में सोचना बेहतर होगा। साथ ही, सर्वर पर इन्फोबेस वाले अनुभाग को डीफ़्रैग्मेन्ट करने के बारे में भी न भूलें।

क्लाइंट डिस्क सबसिस्टम और एसएसडी

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

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

एक धीमी हार्ड ड्राइव कुछ कार्यों को धीमा कर सकती है, लेकिन अपने आप में किसी प्रोग्राम को धीमा नहीं कर सकती।

टक्कर मारना

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

हमने सिस्टम मेमोरी को घटाकर 1 जीबी कर दिया और दो सूचना डेटाबेस लॉन्च किए।

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

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

जैसा कि हम देख सकते हैं, सिस्टम डेटा प्राप्त करने के लिए सक्रिय रूप से नेटवर्क का उपयोग करता है और इसे संसाधित करने के लिए प्रोसेसर; प्रसंस्करण के दौरान डिस्क गतिविधि नगण्य है, यह कभी-कभी बढ़ जाती है, लेकिन यह एक सीमित कारक नहीं है;

अब मेमोरी को 1 जीबी तक कम करते हैं:

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

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

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

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

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

CPU

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

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

निष्कर्ष

तो, 1C धीमा क्यों है? सबसे पहले, यह रैम की कमी है; इस मामले में मुख्य भार हार्ड ड्राइव और प्रोसेसर पर पड़ता है। और यदि वे प्रदर्शन के साथ चमकते नहीं हैं, जैसा कि आमतौर पर कार्यालय कॉन्फ़िगरेशन में होता है, तो हमें लेख की शुरुआत में वर्णित स्थिति मिलती है - "दो" ने ठीक काम किया, लेकिन "तीन" बेहद धीमी गति से हैं।

दूसरे स्थान पर नेटवर्क प्रदर्शन है; एक धीमा 100 Mbit/s चैनल एक वास्तविक बाधा बन सकता है, लेकिन साथ ही, पतला क्लाइंट मोड धीमे चैनलों पर भी संचालन के काफी आरामदायक स्तर को बनाए रखने में सक्षम है।

फिर आपको डिस्क ड्राइव पर ध्यान देना चाहिए; SSD खरीदना एक अच्छा निवेश होने की संभावना नहीं है, लेकिन ड्राइव को अधिक आधुनिक से बदलना एक अच्छा विचार होगा। हार्ड ड्राइव की पीढ़ियों के बीच अंतर का आकलन निम्नलिखित सामग्री से किया जा सकता है:।

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

हमें उम्मीद है कि यह सामग्री आपको "1C धीमा क्यों है" प्रश्न को शीघ्रता से समझने और इसे सबसे प्रभावी ढंग से और अतिरिक्त लागत के बिना हल करने में मदद करेगी।

  • टैग:

कृपया देखने के लिए जावास्क्रिप्ट सक्षम करें