लॉग 4नेट का विस्तार। प्रतियोगी लॉगिंग

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







तुरंत परीक्षण के माहौल के बारे में आरक्षण करें, क्योंकि मेरे तर्कों में मैं परीक्षा परिणामों पर भरोसा करूंगा। I7 प्रोसेसर (4 कोर, 8 हाइपर-थ्रेडिंग को ध्यान में रखते हुए), log4net.Extensions.Console एप्लिकेशन 8 थ्रेड में लॉग ऑन करने के लिए लिखता है, जो मनमाने ढंग से नींद के बाद रिकॉर्डिंग करता है। लॉग प्रविष्टियों की संख्या 10000 है। BulkStarter एप्लिकेशन log4net.Extensions.Console और उनके पूरा होने के लिए इंतजार कर रहा है के 10 उदाहरण शुरू होता है। इस प्रकार, 10 प्रक्रियाएं, प्रत्येक में 8 थ्रेड्स के साथ, एक फ़ाइल में लिखें। स्टॉपवॉच (उपायों के लिए उच्च-रिज़ॉल्यूशन टाइमर) का उपयोग करके इस तरह के परीक्षण में सभी समय विशेषताओं को प्राप्त किया गया था।

FileAppender + MinimalLock

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

• बहुत धीमा (परीक्षण के 1:56 से, लॉगिंग विधि में सीधे कॉल 1:40 लिया गया);
• एक लॉक संघर्ष जब कई प्रक्रियाएं लिखने के लिए एक धागा प्राप्त करने का प्रयास करती हैं (जिसका अर्थ है लॉग के लिए लेखन नहीं)।

MinimalLock के साथ FileAppender कॉन्फ़िगरेशन उदाहरण:

<appender name="FileAppender" type="log4net.Appender.FileAppender"> <file value="D:\1\test-minlock.log"/> <lockingModel type="log4net.Appender.FileAppender+MinimalLock" /> <layout type="log4net.Layout.PatternLayout"> <conversionPattern value="%message%n"/> </layout> </appender>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ConcurrentMinimalLock

एक योग्य प्रतिस्थापन की तलाश में, मैं कोड प्रोजेक्ट पर 2008 के एक लेख में आया - बहु-प्रक्रिया से एकल फ़ाइल में लॉगिंग । लेख में समवर्ती मैनिमलॉक के कार्यान्वयन का वर्णन है, जिसमें संदेश बफ़र किए जाते हैं, और फ़ाइल को लूप में खोला जाता है (जब तक कि लॉक स्थापित नहीं हो जाता है)। सब कुछ ठीक लग रहा है, लेकिन लॉगिंग विधि को कॉल करने का समय 1:20 में से 1:04 है। यानी अभी भी लंबा है। और यह इस तथ्य को ध्यान में रख रहा है कि यह आंशिक रूप से अतुल्यकालिक लॉगिंग है (यदि आवेदन हार्ड-बंद है, तो सभी कतारें खो जाएंगी)।

ConcurrentFileAppender

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

• अमूर्त वर्ग log4net.Appender.AppenderSkeleton से निहित;
• ActivateOptions पद्धति को लागू करें, जिसमें परिशिष्ट का प्रारंभ किया जाता है;
• एक एकल LoggingEvent और LoggingEvent की एक सरणी को स्वीकार करने वाले तरीकों को लागू करें।
• OnClose पद्धति को लागू करें, जो संसाधनों को साफ करता है (log4net में निपटान के समान)।

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

ActivateOptions

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

 public override void ActivateOptions() Dispose(true); // flush     base.ActivateOptions(); //       var path = SystemInfo.ConvertToFullPath(Path); var dir = System.IO.Path.GetDirectoryName(path); if (!Directory.Exists(dir)) Directory.CreateDirectory(dir); _loggingEvents = new Queue<LoggingEvent>(QueueInitialCapacity); FileStream stream = null; Mutex mutex = null; try { stream = File.Open(path, FileMode.Append, FileAccess.Write, FileShare.ReadWrite); mutex = CreateMutex(path); _thread = new Thread(ThreadProc) { Name = "ConcurrentFileAppenderListener", IsBackground = true // logging thread should not prevent an application exit }; _thread.Start(); _stream = stream; stream = null; _mutex = mutex; mutex = null; if (FlushOnProcessExit) AppDomain.CurrentDomain.ProcessExit += delegate { OnProcessExit(path); }; } finally { if (stream != null) stream.Dispose(); if (mutex != null) mutex.Close(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ThreadProc

लूप में विधि ट्राइट गैर-शून्यता के लिए कतार की जांच करती है। यदि कतार खाली नहीं है, तो इसकी सामग्री की प्रतिलिपि बनाएँ, इसे साफ़ करें और इसे डिस्क पर डंप करें।

 private void ThreadProc() { var culture = CultureInfo.InvariantCulture; while (true) { if (!_nonEmptyQueue) //      bool     { Thread.Sleep(QueueEmptyCheckTimeoutInMilliseconds); continue; } lock (QueueSyncRoot) { _currentProcessingEvents = _loggingEvents.ToArray(); _loggingEvents.Clear(); _nonEmptyQueue = false; } Flush(_mutex, _stream, culture, _currentProcessingEvents); _currentProcessingEvents = null; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

लालिमा

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

 private void Flush(Mutex mutex, FileStream stream, CultureInfo culture, ICollection<LoggingEvent> events) { if (events.Count <= 0) return; byte[] buffer; using (var sw = new StringWriter(culture)) { foreach (var e in events) RenderLoggingEvent(sw, e); buffer = Encoding.GetBytes(sw.ToString()); } try { mutex.WaitOne(); stream.Seek(0, SeekOrigin.End); stream.Write(buffer, 0, buffer.Length); stream.Flush(); } finally { mutex.ReleaseMutex(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अंतिम कार्यान्वयन

अंत में, बेस क्लास ConcurrentAppenderSkeleton लिखा गया था:

 public abstract class ConcurrentAppenderSkeleton : AppenderSkeleton, IDisposable { /// <summary> /// Gets a name for a <see cref="Mutex"/>. /// </summary> protected abstract string UniqueMutexName { get; } /// <summary> /// Performs initialization of an appender. Should throw exception if cannot be initialized. /// </summary> protected abstract void ActivateOptionsInternal(); /// <summary> /// Prepares data to a flushing. /// </summary> /// <remarks> /// <para>This method executes in a thread safe context (under <see cref="Monitor"/> lock).</para> /// </remarks> /// <param name="events">Logging events.</param> /// <returns>A prepared data.</returns> protected abstract object PrepareData(LoggingEvent[] events); /// <summary> /// Flushes prepared data. /// </summary> /// <remarks> /// <para>This method executes in a thread-safe context (under mutex).</para> /// </remarks> /// <param name="data">A prepared data to a flushing.</param> protected abstract void Flush(object data); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और इनहेरिटर्स: ConcurrentFileAppender और ConcurrentForwardingAppender ( BufferingForwardingAppender के समान)। उत्तरार्द्ध आपको अन्य परिशिष्टों के समूह को लिखने (फ्लश) की अनुमति देता है। यह महत्वपूर्ण है कि ये अन्य परिशिष्ट अनन्य ताले नहीं बनाते हैं (यानी फ़ाइलएपेंडर + एक्सक्लूसिवलॉक का उपयोग नहीं किया जा सकता है), और इसलिए उन्हें म्यूटेक्स द्वारा सिंक्रनाइज़ किया जाएगा।



परीक्षण के प्रयोजनों के लिए, मैंने एक सेटिंग जोड़ी - जिसमें म्यूटेक्स का उपयोग करके सिंक्रनाइज़ करने के लिए जगह है: या तो कतार से संदेश प्राप्त करने से तुरंत पहले, या केवल एक फ़ाइल पर लिखने के लिए। पहले मामले में, कतारों की संख्या में वृद्धि हुई है (लंबे समय तक ताले के कारण, क्योंकि वे स्वरूपण और रिकॉर्डिंग शामिल हैं), लेकिन इनपुट / आउटपुट लागत में कुछ कमी (10Kb के 10 रिकॉर्ड 100 से 1Kb से अधिक तेज हैं)। दूसरे मामले में, कतार बहुत अधिक नहीं बढ़ती है, ताला में होना कम से कम है (केवल I / O स्वयं के लिए समय), जो अधिक स्केलेबल है।

कसौटी

आपको याद दिला दूं कि एक परीक्षण में 8 धागे के साथ 10 प्रक्रियाओं की 500 एमबी लॉग प्रविष्टि है। नीचे दी गई तालिका विभिन्न परीक्षणों के लिए परिणाम दिखाती है। ConcurrentFileAppender को फाइल के रूप में संक्षिप्त किया जाएगा, ConcurrentForwardingAppender (रिकॉर्डिंग FileAppender + MinimalLock में Fwd + Min के रूप में किया जाता है), और विदेशी संस्करण ConcurrentForwardingAppender है, जहां रिकॉर्डिंग समरूपमैंमिलॉक के साथ FileAppender में किया जाता है, इसे Fwd + Con के रूप में नामित किया जाएगा। कतारबद्ध मतदान के लिए नींद का समय 10ms है। Mutex.WaitOne को केवल रिकॉर्डिंग के लिए IO के रूप में नामित किया जाएगा, स्वरूपण और रिकॉर्डिंग के लिए संपूर्ण।

समय (s) \ Test	MinLock	समवर्ती मिनलोक	फ़ाइल io	पूरी फाइल	Fwd + मिनट io	Fwd + मिनट पूरे	Fwd + con io	Fwd + कोन पूरा
कुल समय	116.6	79.7	11.27	11.6	11.96	11.61	11.7	11.61
logger.Debug	100.36	64.68	0.08	0.07	0.07	0.07	0.08	0.07
बुध कतार की लंबाई	-	-	9	40	185	169	17	25

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



समवर्ती * एपेंडर्स के दो मुख्य लाभ: लॉगिंग सक्षम होने पर मुख्य अनुप्रयोग में मल्टीप्रोसेसिंग और मंदी की व्यावहारिक अनुपस्थिति।

पुनश्च

एक लेख लिखने की प्रक्रिया में, मैंने कुल समय की गणना करने और लकड़हारा.बबग विधि को कॉल करने में एक त्रुटि देखी। मेरे ऐपेंडर्स के साथ, सब कुछ और भी बदतर हो गया, लेकिन मेरा और भी बेहतर के साथ :) लेकिन मैंने मूल परिणाम तालिका को अब और अपडेट नहीं किया, क्योंकि बहुत लंबे समय के लिए, खेद है (त्रुटि यह है कि log4net.Extensions.Console स्टॉपवॉच इंस्टेंस तक पहुंच को असंयमित किया गया था + यह मान 8 से विभाजित करना आवश्यक था)।



संदर्भ:

• Log4net आधिकारिक पेज
• System.Threading.Mutex - एक वर्ग जो .NET फ्रेमवर्क में म्यूटेक्स कार्यक्षमता को लागू करता है
• मल्टी-प्रोसेस से सिंगल फाइल में लॉग इन करना

फाइलें:

• परिशिष्ट कार्यान्वयन और परीक्षण अनुप्रयोगों
• विस्तारित परिणाम तालिका के साथ परिणाम + ods फ़ाइल लॉन्च करें